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PREFACE 


MMiillWi 


The Seasat satellite was launched at 01:12:44 GMT on 27 June 1978 from the 
Western Test Range at Vandenberg Air Force Base, Lompoc, California. The space- 
craft was injected into Earth orbit to demonstrate techniques for global monitor- 
ing of the dynamics of the air-sea interface and to explore operational applica- 
tions. To achieve these objectives, a payload of sensors emphasizing all-weather, 
active and passive microwave capabilities was carried on the satellite. The 
mission was prematurely terminated on 10 October 1978 after 106 days of operation 
by a catastrophic failure in the satellite power subsystem. 

Major mission accomplishments were: 

(1) Demonstration of the orbital techniques required to support the 
mission and sensor operations. 

(2) Demonstration of the simultaneous operation of all sensors for 
periods of time significant to global monitoring. 

(3) The collection of an important data set for sensor evaluation and 
scientific use. 

The early mission termination precluded: 

(1) Demonstration of the planned operational features of the end-to-end 
data system. 

(2) Collection of a global data set to meet overall geodetic and 
seasonal objectives and plans. 

This report, in four volumes, includes results of the sensor evaluations 
and some preliminary scientific results from the initial experiment team activi- 
ties. Scientific and applications studies wi 1 1 continue through FY 80, and will 
be included in the final version of this report. 
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ABSTRACT 


The Seasat Project was a feasibility demonstration of the use of orbital 
remote sensing for global ocean observation. The satellite was launched in June 
of 1978 and was operated successfully until October 1978. At that time, a mas- 
sive electrical failure occurred in the power system, terminating the mission 
prematurely. 

Volume III of the Final Report treats the Ground Systems used during the 
mission life. Included are descriptions of the Operating Organization, the Sys- 
tem Elements, and the testing program. Next, there is a discussion of the various 
phases of the mission: Launch and Orbit Insertion, Cruise, and Calibration. A 

special section is included on the Orbit Maneuver activities. Finally, operations 
during the satellite failure are reviewed and summarized. 
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SECTION I 


INTRODUCTION 


Information contained in this volume, compiled by the Seasat Mission 
Control Team, is the final report for the Project Operations System. The mission 
was planned in phases, which were first documented by the Mission Control Team 
in the Space Flight Operations Plan.* Because of the spacecraft power failure., 
the mission was terminated while the satellite was still in the calibration 
phase, just prior to the planned observational phase. The observational phase 
was planned to start 115 days after launch, and would have continued through the 
remainder of the scheduled 1-year mission. 

The following major topics are discussed in this volume: 

(1) Pre-Launch Phase. 

(2) Launch and Orbit Insertion Phase. 

(3) Orbital Cruise Phase. 

(4) Calibration Phase. 

(5) Orbit Maneuvers. 

(6) Satellite Failure Report. 

Not discussed here is the Seasat Data Utilization Project (SDUP) . After 
the satellite failure, this project was set up to complete the post-flight sensor 
analysis and produce the final sensor and geophysical data records. The SDUP 
activity is still in progress at this writing and will be reported separately 
when complete. 

Other activities of this project are documented in separate volumes of this 
series : 

Volume 1 Program Summary 

Volume II Flight Systems 

Volume IV Attitude Determination 

Abbreviations and acronyms used in this volume are defined in the appendix. 


*Seasat-A Space Flight Operations Plan, JPL internal document 622-42, 15 May 1978. 
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SF.CTION II 


PRE-LAUNCH PHASE 


A. GENERAL 

This section describes the Project Operations System (POS) activities as 
they pertain to the pre-launch phase. This section includes the description of 
functional organizations and their requirements, the design of mission opera- 
tions, the implementation of the Seasat ground data system, and the POS test and 
training exercises conducted to support launch readiness. 

The pre-launch phase included vehicle erection, mating, and checkout pi - 
cedures at the Air Force Western Test Range (AFWTR) located at Vandenberg Air 
Force Base, California. This phase was the final stage of pre-launch prepara- 
tions for most POS elements. Individual subsystems of the POS had by that time 
completed their scheduled implementation, and were prepared to execute the mis- 
sion. The following paragraphs describe the POS organization, the Ground Data 
System (CDS) implementation, and the POS test and training activities as they 
pertained to requirements, schedules, and accomplishments. 


B. PROJECT OPERATIONS SYSTEM ORGANIZATION 


The POS organization was composed of five major systems (Figure 2-1), Er- 
ected by a manager who was responsible to the project manager for the direct 
of mission operations. The manager was responsible for the conduct of the mis- 
sion, which included mission operations planning, development, preparation, and 
execution. The specific POS responsibilities were: 

(1) Establishment of the functional requirements for and the overall 
functional design of the GDS required for the conduct of mission 
operat ions. 

(2) Placement of requirements on all supporting elements of the POS by 
preparation of the Support Instrumentation Requirements Document 
(SIRD) . 


(3) Design, development, and test of mission-dependent computer programs 
and special purpose hardware required for mission operations. 


(A) Integration of the GDS elements. 


(5) Preparation and execution of the project operations test and train- 
ing plan. 

(6) Establishment of the mission operations organization and interfaces 
with other supporting organizations. 
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Figure 2—1. Project Operations System Interface Organization 





(7) Conducting of the satellite and Mission Operations System (MOS) 
compatibility test, 

(8) Planning and direction of mission operations. 


1, Chief of Mission Operations 

The Chief of Mission Operations Ao) \ as responsible to the POS manager, 
and had operational responsibilities foi m I ion manaecmert and the conduct of 
mission operations. CMO responsibilities < re to: 

(1) Direct the POS organization. 

(2) Conduct mission operations according to mission plans and any guide- 
lines and constraints specified by the project manager. 

(3) Coordinate and direct analysis and planning activities of the POS. 

(4) Specify mission operations plans, policies, and instructions to the 
Mission Control Team (MCT) for execution. 


2. Mission Teams 

a. Mission Operations Teams . The mission operations teams consisted of 
11 elements representing the use of committed flight support resources as pro- 
vided by the Jet Propulsion Laboratory (JPL) , Goddard Space Flight Center (GSFC) , 
Lockheed Missiles and Space Company (LMSC) , and non-NASA agencies. Each of the 
mission operations teams (Figure 2-2) performed both planning and operational 
functions and interfaced with the MCT. The MCT, composed of the deputy CMO and 
Assistant Chiefs of Mission Operations (ACMO) , was delegated certain responsi- 
bilities by the CMO. 

Because of the locations of the various mission operations teams, the CMO 
and deputy CMO rotated between JPL and GSFC to effect mission control and to 
direct activities carried out by the mission operations teams. 


b. Mission Control Team . The function of the MCT was to coordinate and 
control the activities of the mission operations teams in their execution of 
mission operations. During the primary mission, the MCT was staffed 24 h a day, 
7 days a week by an ACMO. The on-duty ACMO was collocated with the Satellite 
Performance and Analysis Team (SPAT) and the Project Operations Control Center 
(POCC) Operations Support Team (POST) in the POCC. The essential activities 
coordinated by the MCT were ground support scheduling, command management sup- 
port, tape recorder management, maneuver operations management, clock control, 
real-time pass activities, and discrepancy and status reporting. 


c. Mission Planning Team . The basic function of the Mission Planning 
Team (MPT) was to generate a Command Request Profile (CRP) that reflected the 
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desires of the project and experimenters. The CRP was relayed to Seasat project 
operations elements at GSFC, where it was developed into satellite command loads. 

The MPT was located at JPL and used JPL computers. A CRP contained time- 
ordered sequences of requested stored program commands and appropriate comments. 
The comments consisted of orbit-related events, recommended real-time commands, 
and other Information useful for interpretation of the CRP. 

The planning cycle to develop the CRP comprised a 4-week period, and inputs 
were received from the experiment teams, SPAT, MCT, PQCC, Spaceflight Tracking 
and Data Network (STDN), and project management. The MPT performed CRP con- 
straint checks to ensure that satellite subsystem constraints were not violated. 
The MPT was responsible for performing trend analysis and for monitoring the 
satellite status with data obtained from JPL’s Project Data Processing System 
(POPS). The MPT maintained up-to-date orbit information, recommended maneuver 
days, and specified the desired orbital elements. The MPT also designed sensor 
sequences to accommodate targets of opportunity. 


d . Satellite Performance Analysis Team . The SPAT consisted of a lead 
monitor analyst and two satellite subsystem analysts. The basic functions of 
the SPAT were to provide the technical coordination for operation of the satel- 
lite system, monitor the performance of the system, and provide the data analy- 
sis required to provide information relative to satellite system status and 
performance. Specific responsibilities of the SPAT were to validate mission 
profiles, command loads, and real-time commands prior to transmission to the 
satellite or before input to the Command Management System (CMS). The SPAT was 
responsible for the definition of all GSFC-generated command loads for maneuvers, 
sensor targets of opportunity, and satellite configuration. In real time, the 
SPAT evaluated satellite system performance and status. In addition to perfor- 
mance monitoring, the SPAT provided data analysis of real-time data for trends 
and anomalous behavior in the satellite system and sensors. The SPAT prepared 
an inflight performance estimate report conforming with these performance and 
trend data. 


e. Orbit Determination . The orbit determination support function for 
Seasat was directed by the orbit computation engineer, and was grouped into the 
following categories: 

(1) Launch and early orbit support. 

(2) Operational orbit support. 

(3) Definitive orbit support. 

(4) Observational tracking data support. 

The launch and early orbit support function consisted of on-line computing 
support during the launch trajectory phase and the early phase of the achieved 
orbit. The time duration of the early orbit determination phase was dependent 
on station distribution and availability of observational tracking data. The 
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primary objective of the operational orbit support function was to furnish 
predicted orbit-related information to designated participants throughout the 
Seasat project. Some of the participants receiving the predicted orbit-related 
information were the POCC, Attitude Determination System (ADS), Information 
Processing Division (IPD), STDN, and JPL. The objective of the definitive orbi- 
tal operations support function was to provide definitive orbital-related infor- 
mation to other recipients. The objectives of the observational tracking data 
support function were to: 

(1) Receive, store, retrieve, and pre-process S-band and quick-look laser 
data. 

(2) Receive and pre-process the full-rate laser data and distribute it 
to the National Space Science Data Center (NSSDC) and designated 
rec ipients. 

f. Flight Maneuver Operations Center Team . The basic functions of the 
Flight Maneuver Operations Center (FMOC) team were to plan and evaluate orbit 
maneuvers executed to meet mission and project requirements. The FMOC team was 
located at GSFC, was headed by a GSFC flight mission analyst, ar i used computers 
located in the GSFC Mission Operations Computing Facility (MOCF) . 


g. Attitude Determination Team . The basic functions of the Attitude 
Determination (AD) team were real-time yaw attitude computation, quick-look 
attitude determination u.iing whole-orbit playback data, and definitive attitude 
determination on all data ri eived from IPD with turnaround in time to meet the 
total 6-day Project Data Package (PDP) commitment. The AD team leader was the 
attitude computation engineer. 

Quick-look and real-time data processing were performed as requested by 
the project. A complete orbit set of attitude data results were written on disk 
packs for access by the LMSC simulator software. These complete orbit data were 
also used to compile disk files for the LMSC power profile software. 


h. Information Processing Division . The basic function of the IPD was 
to process satellite playback telemetry data and to prepare a PDP for use at 
JPL. The IPD is located at GSFC, and the team leader was the data processing 
engineer. The specific responsibilities of the IPD were to pre-process playback 
telemetry data, maintain accountability, and provide quick-look data as requested 
by the project. IPD assembled attitude, orbit, and command data for the PDP and 
for GSFC user organizations. 


i. Command Management Facility (CMF) . The basic function of the CMF 
was to accept (via the POCC) CRPs from the MPT located at JPL, and to generate 
the resulting command memory loads with a corresponding English descriptive 
memory load map and a Mission Sequence of Events (MSOE) . The memory loads, map, 
and MSOE were transmitted to the POCC. The CMF team leader was the command 
management specialist. CMF provided the project an interface to edit all inputs 
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of CRPs. With the inputs from the Seasat scheduler, CMF determined memory loads 
in size, time span, remaining capacity of satellite memory, and capacity of the 
station-to-uplink system. 


j. POCC Operations Support Team . The POST was staffed by contractor 
personnel and responded to technical direction and requirements provided by the 
GSFC Seasat Control Center Operations Manager (CCOM) . The team leader was the 
data operations controller located in the POCC. The basic function of the POCC 
was to serve as the facility in wh .ch project personnel monitored and controlled 
the operations of the Seasat spacecraft. The POCC was staffed around the clock 
by the GSFC POST, the JPL MCT, and the LMSC SPAT teams. The basic function of 
the POST was to provide the POCC operations support and equipment maintenance 
required to enable the MCT and SPAT to monitor and control the spacecraft. 

The POCC scheduler generated the weekly STDN support reqiest using project- 
provided generic requirements and special activity support requirements. The 
Seasat scheduler also scheduled non-NASA supporting stations, including the 
Fleet Numerical Oceanographic Center (FNOC) , as required by the project. 


k. Network Operations . The basic function of the STDNs was to provide 
station coverage from among the 12 comritted stations on each orbit during nor- 
mal operations following launch. The network controller was the STDN team 
leader. The stations were responsible for providing real-time telemetry and 
command data interfaces via NASCOM to the POCC during each orbital pass, record- 
ing playback data as scheduled, performing station delay measurements for satel- 
lite time correlations, and taking ranging and tracking data as scheduled. 


1. Experiment Data Processing . The experiment data processing required 

to generate the Sensor Data Record (SDR) in the Mission Control and Computing 
Center (MCCC) was the responsibility of the MCCC Data Management Team (MDMT) . 
This team was led by the mission data management supervisor. The MDMT was a 
multi-mission records processing team jointly funded by the Voyager and Seasat 
flight projects. 


3. Non-NASA Agencies 

a. Fleet Numerical Oceanographic Center . The United States Navy's FNOC 
located at Monterey, California, is the primary Navy center for computer analy- 
sis and prediction of both oceanographical and meteorological parameters. The 
team leader was the FNOC staff duty officer. The FNOC participated in the Seasat 
project as a result of a Memorandum of Agreement (MOA) between the Department of 
Defense (DOD) and NASA. According to that MOA, FNOC provided a near-real-time 
user data demonstration system. FNOC received data from the Fairbanks, Alaska 
(UFA) STDN station within 6 hours from the time the data were recorded by the 
spacecraft. FNOC processed these data and determined their engineering unit 
values. Figure 2-3 shows the data flow path for the receipt of world-wide data. 
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Figure 2-3. Data Transmit Paths for Seasat 





b. Shoe Cove Tracking Station (Canada) . This station received both 
low-rate telemetry and the Synthetic Aperture Radar (SAR) telemetry data links. 
The facility was primarily interested in receiving SAR data; therefore, only 
selected low-rate telemetry parameters were detected, synchronized, and process 
sed. The SAR data were received and processed using the same type equipment 
used by the STDN. A voice line was used for coordination between the POCC and 
the station during real-time passes and reporting from the station. 

Station control information, such as pass schedules, orbital elements, and 
SAR demodulation control statements, was provided via telex from GSFC to the 
Canadian Center tor Remote Sensing (CCRS) at Ottawa and Prince Albert, where 
station predictions were generated. 


c. Oakhanger Tracking Station (England) . This station received both 
low-rate telemetry and SAR telemetry data links. The station was receiving and 
processing SAR data and 25-kb/s real-time data in cooperation with the European 
Space Agency (ESA). A voice line was used for real-time pass coordination 
between the POCC and the station. Selected telemetry parameters, which had been 
detected, were also reported by voice. 

Station control information, such as pass schedules, orbital elements, 
and SAR demodulation control statements, was provided from GSFC to Oakhanger 
via tt lex where station predictions were generated. 

d. Tromso Tracking Station (Norway) . Station support was scheduled to 
start in mid-October 1978. Initially, the station would receive low-rate (25 
kb/s) data only. Interface with Seasat operations was to have been minimized 
because of the passive receive-only telemetry mode of operation. Orbital ele- 
ments for predict general ion at the station were to be provided from GSFC via 
telex. The station w as required to provide the CMO with biweekly status reports, 
indicating actual Seasat tracking activity. 


C. GROUND DATA SYSTEM IMPLEMENTATION 

The Ground Data System (CDS) elements implemented to support the Seasat 
Mission Data System (MDS) are «?hown in Figure 2-4. For a more in-depth review 
of each CDS element and specific interfaces, refer to the Space Flight Operations 
Plan . * 

Ail 0 jH elements neves* ary ior supporting real-time mission operations 
were brought to u support readiness condition prior to launch. The telemetry 
housekeeping tape (quick- look) generation system readiness was late, so with 
operational confidence being tow, the AFWTR and NASA Kennedy Space Center (KSC)/ 
Western Launch Operations Division (WLOD) facilities were requested to provide 
early orbital support. Difficulties in the launch real-time satellite data link 


* Seasat-A Space Flight Op e rations Plan , JPL internal document 622-42, 15 May 1978. 
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from the Agena second-burn coverage prompted a late request to have the United 
States Air Force (USAF) provide backup record-only launch support from the 
Indian Ocean S-band station at Mahe. 

Several GDS elements necessary for non-real-time data support of the Seasat 
mission were not ready for launch. These elements were: 

(1) IPD. 

(2) NASA Ground Communications System (NASCOM) (224 kb/s STDN station 
Merritt Island (MIL) to GSFC to FNOC) . 

(3) FNOC. 

(4) Laser deployments (MOBLAS 5-8). 

(5) STDN station Oakhanger, United Kingdom (UKO). 

(6) Shoe Cove/CCRS. 

These implementation problems are discussed in the following paragraphs, 
along with GDS elements requirements, implementation schedules, and accomplish- 
ments. A GDS lien list is provided at the end of this section. 


1. Mission Planning Subsystem 

The primary functions of the Seasat Mission Planning Subsystem (MPS) were 

to: 


(1) Provide Command Request Profiles to the Mission Control Team at 
GSFC. 

(2) Develop maneuver and orbit maintenance strategies and to specify 
maneuver execution periods and desired results. 

(3) ’ .ovide planning products to experiment and data processing groups. 

(4) Monitor long-term satellite performance to establish sensor operat- 
ing constraints. 

The first three functional capabilities were developed, tested, brought to 
full operational status, and successfully used throughout the Seasat mission. 

The fourth function, long-term performance monitoring, was never successfully 
demonstrated, partly because of lengthy delays in the availability of processed 
data and partly because of the lack of availability of a SPAT representative to 
the MPS. To the extent that this fourth function existed, it was performed 
within the SPAT at GSFC. 


a. Sequencing . The sequencing elements of the MPS involved developing 
and transmitting the CRP to GSFC, which included the use of several information 
interfaces and two major software sets operating on the 1108 computer systems. 
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The information interfaces were between the MPS and the SPAT sensor experiment 
representatives, the sensor engineering assessment managers, and the orbit 
determination group in Code 370 at GSFC. One of the software sets was the 
operational version of the Satellite Mission Design Program (SAMDPO) developed 
by the Mission Design Section at JPl from a predecessor program (SAMDP2.0) used 
in the original Seasat mission design. The other software set was the mission 
planning software set developed as a Seasat-peculiar item by Alta Vssta Techni- 
cal Services under contract to the Mission Design Section at JPL. Functional 
flow through the MPS (Figure 2-5) involved the collection of orbital elements 
from GSFC Code 570 to drive SAMDPO, engineering constraints and requirements 
from SPAT, and sensor sequencing requirements from both the experiment represen- 
tatives and the sensor managers for engineering assessment. The SAMDPO output, 
together with the other inputs, served as the input to the mission planning 
software set which resolved orbital event-related times to GMT command times, 
expanded macro requests (satellite group commands), resolved time conflicts 
between commands, and flagged satellite command restraint violations. This was 
an iterative process with two levels of project review prior to final output. 

The first review was at the input level, where the project office reviewed the 
sensor inputs and engineering constraints for completeness and appropriateness. 
The second review was a detailed command review by the Seasat Project Office 
and other interested personnel. The final output was a CRP nominally covering 
a 7-day period written on an MCCC system 360-compatible tape for formatting and 
transmission via high-speed data line to the POCC Sigma 5 computer system at 
GSFC. 

£• The pacing item in the sequencing development activity was the data inter- 

face with CMS. Preliminary agreement was reached by October 1976 to the degree 
required to permit CMS design to begin. Several changes and remaining uncer- 
tainties, notably the addition of the Global Positioning System (GPS), lack of 
precise knowledge of the information available from Code 570, and uncertainties 
in STDN station scheduling, led to delays in the final specification of the 
MPS/CMS interface. The GPS was subsequently removed from the satellite when it 
was determined that the required orbital data could be generated with sufficient 
accuracy in SAMDPO, and a division of responsibility between MPS and MCT was 
developed for tape management, which circumvented the station scheduling prob- 
lems, so that the requirements for MPS and CMS could be established with the 
required firmness by June 1977. At this point coding of Mission Planning Soft- 
ware System (MPSS) Version 0.1 could be completed. Three test tapes were deliv- 
ered to CMS for testing, resulting in the identification of several changes 
required on both sides of the interface. The MPS changes were accomplished in 
the next two months. The high-speed data line capability, originally scheduled 
for mid-November 1977, was delayed several months, so that data exchange between 
MPS and CMS continued through tape deliveries. Mission Planning Software System 
£ Version 0.2 was successfully acceptance-tested and placed under change control 

t. on 31 January 1978. With the completion of sensor hardware delivery and instal- 

lation at LMSC, the sensor representatives began developing more detailed plans 
for the sensors, requiring additional modifications to the software, but in the 
meantime software version 0.2 was delivered and installed as Mission Operations 
Software System (MOSS) Version 1.0 on 16 May 1978. The launch version (MOSS 1.1) 
was delivered and installed on 22 June 1978. 

The SAMDPO software was developed as a separate program from its predeces- 
sor beginning in spring 1977. The basic requirement for the program was to 
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Sequencing Functional Flow 









create a time-ordered set of orbit-related events for use as command triggers or 
operational information by the planning software or operational personnel (Table 
2 - 1 ). 


A development version of the program was running by late summer 1977, 
although some of the requested orbital events had not yet been implemented. The 
development version output file was complete enough to permit end-to-end testing 
of the MPS software from September to December 1977. SAMDPO was internally 
tested and certified for use on 12 February 1978. Integrated testing with the 
planning software, however, indicated that the certified version still did not 
have the full operational capability required. Several of the orbital events 
required were computationally incorrect, others were intermittent, and still 
others had not yet been implemented. Refinement of the operations concept also 
had yielded new requirements for SAMDPO outputs. Throughout the next 2 months, 
emphasis was placed on improving the internal accuracy of SAMDPO and revising 
its subroutines to reflect improvements already incorporated in a companion ver- 
sion of SAMDPO 3.0. Considerable effort was expended on increasing computational 
efficiency, as SAMDPO had the longest running time of all of the MPS software. 

By May 1978, there was considerable concern that an operational version of 
the program would not be available for launch. Accordingly, the list of require- 
ments yet to be validated was examined and priorities assigned. All mandatory 
items were incorporated first and installed in an operational mission-built ver- 
sion of the program on 25 May 1978. Work continued on the non-mandatory require- 
ments. As each was brought on line in the development version, it was tested 
against the mission-built version and validated by the planning software. MOSS 
1.1, installed 22 June 1978, contained the updated version of SAMDPO. There 
still remained some items to be implemented in SAMDPO at launch, and these Items 
were worked on throughout July and August 1978. During September 1978 work on 
the new version of SAMDPO was temporarily halted because of resource limitations. 
By the time of the satellite power subsystem failure on 10 October 1978, the new 
version was complete and awaiting integrated testing and validation prior to 
installation on the operational system in MOSS 1.3. 

Three types of tests for various versions of SAMDPO were accomplished 
throughout the program: 

(1) Internal tests were conducted against previous versions of the pro- 
gram or against standard test runs on related programs (SAMDP2.0 and 
SAMDP3.0) . 

(2) External tests compared the output of SAMDPO for standard test runs 
on the GSFC Code 570 software. 

(3) Integrated tests were run using the SAMDPO output file as the driver 
for the mission planning software. 

Special input checking routines had been incorporated in the planning software 
to identify missing or inconsistent entries in the SAMDPO output file, such as 
event start without an associated event end, non-eonseeut ive revolution numbers, 
etc. Integrated testing was conducted on an as-developed basts rather than as- 
delivered, so that not only the existing MOSS version of SAMDPO but also the 
latest developmental version was always available for operational use. This 
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incremental approach to testing permitted early use of each validate'* program 
improvement, and also permitted considerable Insight into the effect of individ- 
ua 1 c han ge s on the ba 1 ane e o f t he p r ogr am . 


b # Orbit Maintenance , Pre-launch planning called for early adjustment 
of the Seasat orbit so that a stable orbit optimized for sensor data acquisition 
cou.d be achieved within 30 days of launch. The orbit selected was a 3-day 
near-repeat orbit in which the ground trace laid down in A3 revolutions (revs) 
would be displaced 18.5 km (10 nm) to the east during the next A3 revs. After 

5 months of operation in this orbit, the complete equator would have been crossed 
every 18.5 km, setting up a uniform sensor sampling grid. During this period, 
maneuvers to maintain the 18.5-km spacing were to be performed as required. It 
was also planned to interrupt the grid buildup when an exact overflight of the 
Bermuda STDN station could be achieved to perform an exact 3 day repeat experi- 
ment over Bermuda, then return to the 18.5-km grid buildup. During the second 

6 months of the mission, it was intended that a different grid buildup would be 
used to provide a different global sampling characteristic. 

The MPS responsibilities lay in the areas of development of maneuver strat- 
egy, the specification of post-maneuver orbital elements required, and the selec- 
tion of maneuver days. The maneuver mode ing, thruster calibration, command 
generation, and maneuver execution were all responsibilities of the Maneuver 
Operations Planning Team (M0PT> at GSFC. MPS support in the pre-launch training 
and operational readiness testing activities was given on an as-needed basis. 

By launch, the complete maneuver area had achieved a high state of readiness. 
Detailed orbit maneuver information is contained in Section VI. 


c. Planning Products . Several planning products and planning aids were 
produced by the MPS during the pro-launch and flight activities. These aids 
included orbit calculators, ascending node tables, computer plots, map overlays, 
tabular listings of events of interest, computed products, and special analyses. 
Planning product users ranged from MCT to experiment team members to data users 
outside of the project framework. The products could generally be classified as 
operational aids, data acquisition aids, or informational aids. Their classifi- 
cation generally denotes both their source within the MPS and also their ultimate 
use . 


The operational aids were generally produced by the Mission Planning Soft- 
ware System as a by-product of the process of preparing the CRP . The principal 
users were the members of the MCT at GSFC, the intent being to provide the MCT 
with the information required to aid in STDN station scheduling and real-time 
command generation. The tv>/o routinely produced operational aids were a tape 
recorder management aid (TRP ,AN) and a SAR real-time command aid (SARPLN) . The 
TRPLAH listed all of the potential tape recorder playback sites for each tape 
load and flagged the time available for playback. By using TRPLAN, the ACMOs 
were able to select primary and secondary dump sites for the satellite tape 
recorders. in this manner, tape recorder read-in management was decoupled from 
the tape recorder read-out management, which was dependent on knowledge in 
advance of station scheduling. Although decoupling did simplify the activity, 
both in the MPS and MCT, it did depend on using a fixed-length read-in, which 
resulted in a loss of efficiency in the use of prime tape dump stations. This 
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loss seriously impacted the data recovery and assembly at GSFC. Investigations 
into the possibility of changing the read-in algorithm to increase efficiency of 
usage, specifically of the STDN station Fairbanks (ULA), indicated that no sim- 
ple algorithm could be developed that did not depend on some knowledge of station 
scheduling further in advance than the network schedulers normally worked. The 
only alternative to this loss of efficiency would have been to place the respon- 
sibility for both read-in and read-out tape management with the MCT at GSFC. 

This was rejected as imposing too great an additional load on the MCT. 

SARPLN was intended as an aid to the MCT if targets of opportunity were 
identified and requested by the pro ect without sufficient time to exercise the 
MPS planning capability. SARPLN identified the beginning and end of every pos- 
sible SAR pass within a given time span, and also included such pertinent infor- 
mation as satellite eclipse times and station elevations. This information, 
together with the SAR group commar.us residing in the CMS and the table of Sensi- 
tivity Time Control (STC) and Pulse Repetition Frequency (PRF) commands as a 
function of satellite altitude, provided the MCT with the capability to hand- 
generate any requested SAR pass. 

The data acquisition aids were those produced by the MPS generally using 
the SAMDP3 program for use by the experiment teams to determine opportunities 
for acquiring data at specific locations. Chief among these aids was the 
SKATRAKTM satellite tracking calculator and its associated tables of predicted 
ascending and descending node locations and times. The calculator is a set of 
polar projection Earth maps with overlays which provide satellite and sensor 
swath geometry and timing information. It is similar to the orbit calculators 
often used by previous programs fe providing approximate information for Earth 
orbiters. To use the calculator, it is necessary to have some known orbital 
position and time. This was provided by compiling the set of node positions 
and times with the calculators. These were updated each time the essential 
characteristics of the expected orbit changed; that is, updates were issued 
after the decision to delay orbit adjust and after the design of the actual orbit 
adjust maneuvers was complete. An additional update was scheduled for distri- 
bution on completion of the exact 3-day repeat experiment over Bermuda. The 
calculators proved accurate enough that they were **sed by experiment teams, 
notably the SAR and SASS teams, to produce comman* requests. 

Specially produced computer plots and map overlays were also generated in 
response to specific requests. These also were generated using the SAMDP3 pro- 
gram. The primary users were those interested in special experiments such as the 
Gulf of Alaska Sousa t Experiment (GOASEX) . 

In urination aids were provided from a number of MPS sources to a variety 
of interested parties. A human-readable version of the CRP, desigated TYMLYN, 
was produced each week for the use of all parties who required detailed infor- 
mation on planned science activities. A special SAR request listing was pre- 
pared weekly to indicate the beginning and end of all requested SAR information. 
Another SAR listing maintained a running accounting of cumulative on-times in 
the previous 24-h period for the use of the SAR and satellite electrical power 
personnel. Special analyses and information tabulations were provided in 
response to special requests from those associated with the project. 
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In addition to the planning products, there were also user requests for 
products that would aid in the processing of received satellite data. Special 
SAMDP3 runs were made to provide satellite geometry data to the SAR data process- 
ing group to use as inputs in the SAR processing. 


2. POCC Implementation 

a. Hardware and Software 

Requirements As described ir the SIRD, project-unique requirements 
were to: 

(1) Generate a Command Master Data File (CMDF) of all commands, including 

time of occurrence, initiated from the control center. 

(2) Monitor and correct the spacecraft on-board GMT clock. 

(3) Compute and compare solar array tracking angle and yaw angle in real 

time using satellite-predicted orbit, sun ephemeris, and telemetry 
readouts. 

(A) Format and transmit STC and PRF settings to the STDN SAR data 
formatter control unit. 

(5) Establish JPL/POCC hard-link for transmission of mission planning 
command data. 


Implementation of Requirements . All major requirements were resolved using 
established documents such as the Support Instrumentation Requirements Document 
(SIRD) , NASA Support Plan (NSP) , etc.. Details of requirements were resolved 
by GSFC and JPL engineering personnel. When requirements crossed GSFC organiza- 
tional elements and interagency boundaries. Interface Control Documents (ICDs) 
were established with appropriate signatures. The POCC was directly responsible 
for six of these documents; two were initiated from JPL as a joint effort. The 
POCC also established a sensor processing agreement, which determined and defined 
all POCC quick-look requirements for monitoring the performance of the five 
on-board sensors. This agreement was approved by the six agencies. 

Concurrent with the Seasat software development, a new Mission Operations 
Room (MOR) , office facilities, and a three-computer switching system (for ade- 
quate computer back-up support) were developed. Although this was not a direct 
requirement for Seasat, the Multi-Satellite Operations Control Center (MSOCC) II 
was established to provide a dedicated MOR for Seasat personnel and the scheduled 
availability of three Sigma 5 computer systems for support. 

Software and hardware designs were implemented on or ahead of schedule. 
Firming of software requirements occurred in March 1977 at a Univac /GSFC /JPL 
critical Software Design Review (SDR). The most difficult task, which remained 
essentially on schedule, was the General Electric (GE) switching system hardware 
integration, which occurred during on-going AE and 0S0 spacecraft operations. 
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This was accomplished with minimum impact to either on-site operations or Seasat 
development. This effort also included the first use of 4800-bit NASCOM trans- 
mission blocks, hardware block polynomial decoders, solid-state switching with 
microprocessor control, color configuration cathode ray tube (CRT) display with 
light-pen CRT switching, and color satellite system command display with light- 
pen command execution. The two most difficult new (not generic) software tasks 
were to design. Integrate, test, and maintain schedules for the JPL interface for 
command input and the universal time correction and correlation requirements. 
Although the end-products were satisfactory, these two elements consumed so much 
time because they were new, that it was difficult to plan, test, and generate. 

The block telemetry scanning radiometer (SR) format also created a new data base 
and generated a software design philosphy which to some extent did Impede 
development, but proved to be a better way of processing data. 

Testing . In addition to the contractor (Univac and GE) obligation of 
module, system, and regression testing, a test team was formed. This team con- 
sisted of JPL, Univac, and GSFC operations and engineering personnel whose purpose 
was to test all software deliveries before they were used in operations. The test 
program objective was to generate and test a new software delivery approximately 
every 2 weeks. A new delivery would contain new requirements (which were mini- 
mum), enhancements, discrepancy corrections, and additional scheduled capabili- 
ties. This test effort began on Friday and progressed through the weekend, and 
the system was generally made available on Monday. The method of joint and 
weekend testing proved to be successful, although exhausting to all participants. 

Another important testing event was the spacecraft /POCC compatibility test. 

A spacecraft test plan was co-authored by GSFC and JPL, written foi' both engineer- 
ing and mission-oriented objectives, and approved as a joint LMSC, GSFC, and JPL 
effort. The test, which required approximately 18 h, was very successful, even 
though the timelines and all operations objectives were not met. 

Subsequent to spacecraft launch, other mission operation tests were per- 
formed with engineering support. A software u*.er guide was prepared and delivered 
with the controlled software system tapes, according to GSFC document OCD-2X-038-1 , 
and a formal enhancement and discrepancy system was established from a G. FC 
Operating Control Directive (OCD) . The software user guide was used as the princ- 
ipal training aid along with 2 weeks of formal spacecraft operations and mainte- 
nance and operations (M&O) training, on-the-job training (OJT) , and one-on-one 
training. After launch, a 6-month, 3-man follow-on Univac support contract was 
in effect to continue necessary maintenance of the Seasat software system. 

Schedule . All items related to POCC development were milestoned and pre- 
sented to various GSFC, NASA headquarters, and JPL elements. This material was 
last presented at the October 1977 review at JPL and the 30-day and 7-day pre- 
launch reviews at GSFC. It also included such things as concerns, contingencies, 
capabilities, and status summaries. 


b. Operations and Maintenance Support 

Requirements . POCC operations requirements are documented in the SIRD, 

NSP, JPL Space Flight Operations Plan (SFOP) , GSFC Mission Operations Plan (MOP), 
GSFC Network Operations Support Plan (NOSP) , etc.. Table 2-2 provides a summary 
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Table 2-2. Seasat POCC Operations Support Team Responsibilities 
(O&M Contractor Support) 


Post personnel will: 

(1) Maintain the POCC equipment. 

(2) Operate the POCC computers. 

(3) Coordinate, control, and monitor POCC equipment configurations 
and data flow: 


(a) 

POCC. 

TLM/CMD/SAR 

► STDN 

(by 

POCC- 

CRP/MSOE 

► JPL 

(c) 

POCC. 

CRP/MSOE 

► CMF 

(d) 

POCC. 

, TLM 

► ADS 


(4) Coordinate scheduling of STDN support. 

(5) Schedule and coordinate transmission and retransmission of 
playback. 

(6) Provide verbal briefings and direction to the STDN during 
pre-pass, pass, and post-pass operations. 

(7) Transmit real-time commands and command memory loads to the 
spacecraft under the direction of the project. 

(8) Generate and transmit SAR demodulation control data to ULA, 

MIL, and CDS stations via data link, and to non-STDN stations 
via telex. 

(9) Process microsecond time-tagged real-time telemetry data for 
computation of spacecraft clock time offsets. Distribute time 
offsets to the project MCT, IPD, CMF, ADS, FNOC, and others, 
if required. 

(10) Participate in the pre-launch checkout of the POCC and its 
external interfaces, including participation in training 
exercises and simulations. 

(11) Maintain accountability for POCC/project operations support 
information and data (e.g., support schedules, scheduling aids, 
ephemeris tapes, predicted slant range tapes, memory load 
tapes, etc.). 
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of the operations and maintenance (O&M) support provided by the POCC Operations 
Support Team (POST), and Figure 2-6 shows the many POCC operational and data 
interfaces required to support the Seasat mission. 

Implementation to Meet Requirements . POCC O&M support was provided by 
contractor personnel under the direction of the GSFC control center operations 
manager. O&M personnel also assisted with hardware and software implementation 
and engineering tests, under the direction of the GSFC control center operations 
manager and systems manager. 

POCC O&M implementation consisted of forming and training the POST to 
support Seasat operations, and developing operational procedures. Staff buildup 
began in September 1977, when an Individual with 12 years of control center 
operations experience was assigned as the Seasat operations coordinator. Other 
positions were filled as the workload increased, with all key positions filled 
by January 1978. To start out with experienced operations personnel, two data 
operations controllers from the Orbiting Solar Observatory (0S0) POCC and two 
from the Atmosphere Explorer (AE) POCC were assigned to Seasat. Replacements 
were assigned and trained for 0S0 and AE before this action was te *n. Seasat 
command operator positions were filled in a similar manner. 

The Seasat operations coordinator worked with the POCC manager to develop 
approximately 20 OCDs that specified the operational procedures to be used by the 
POST for the Seasat mission. These directives covered the operational interfaces 
with the many organizations shown in Figure 2-6 and with internal POCC operating 
procedures. Development of these procedures was a time-consuming, but very 
beneficial task. 

Tables 2-3 and 2-4 summarize the formal (classroom) and informal training 
received by the POST personnel. Training was provided by personnel from GSFC, 

JPL, I.MSC, Univac, GE, and RCA. 

Testing . The POST participated in a great deal of testing, much of which 
was also useful for training purposes. POST personnel assisted the control center 
systems manager (CCSM) with engineering tests between the POCC and the organiza- 
tions shown in Figure 2-6. 

One major undertaking of the POST was the conduct of pre-launch POCC/STDN 
data flow tests and the evaluation of the results of these tests. A detailed 
test plan was prepared by the POST that outlined the tests to be performed, their 
purposes, the forms to be used for recording test results, and also identified 
the personnel responsible for supporting the tests. Eighty POCC/STDN data flow 
tests of 60 to 90 min each were conducted between 28 March 1978 and the launch 
date. Most of these tests were successfully completed with all stations by 
early May. Tables 2-5 and 2-6 summarize the testing status as of 11 May. Early 
data flow tests showed missing or incorrect time-tagging of the telemetry data 
by the STDN because special equipment modifications to provide microsecond 
resolution time-tagging for the Seasat mission had not yet been installed at the 
stations . 
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Figure ?-6. Seasat Project Operations Control Center Interfaces 




Table 2*3. Formal Classroom Training 


Formal Training Comp la tad * 

(1) Spacecraft Training Complttad 

Ca iaral overview presentation 

Detailed training claeeea ........ 

(2) Software Operations Classes Completed . . 

Classes 

(3) Hardware Maintenance Training Completed • 
New Hardware 

General Purpose Console (GPC) . . . 
GPC/GC electronic switcher system . 
Simulator /line test unit (PDP 11/34) 

Existing Hardware .... 


3/17/78 

1/19/78 

10/12/77 (1 day) 

1/10/78 co 1/19/78 (8 days) 

12/22/77 

12/12/77 to 12/22/77 (9 days) 
3/17/78 

11/28/77 to 12/2/77 (5 days) 
2/13/78 to 2/24/78 (10 days) 
. 2/28/78 to 3/3/78 (7 days) 

3/6/78 to 3/17/78 (10 days) 


Slgna 5 systems overview 
KVBP/CRTs 

Controller multiplexers for driving KYBO/CRTs and GPCs 

Stripchart rccordars 

Data products lint printers 


Table 2-4. Informal Training 


Informal Training Completed 


6/23/78 (last simulation with STDN) 


(1) Operations Training 

POCC personnel who attended formal software and spacecraft training class 
provide OJT to remaining POCC personnel. 

POCC personnel regularly supported: 


Engineering tests 
Intra/inter-team tests 
Data flow tests 
Simulations 


Primarily from January 1^78 to launch 


Test and simulation support resulted in: 

Refinement of OPS procedures 
Familiarization with the POCC system 

Familiarization with external interfaces , including the STDN configuration 
and project data formats 

(2) Hardware Training 

Maintenance personnel assisted with hardware installation checkout* and malntananca. 


Tabl« 2-5. 


DDPS Phase I, Program 2, POCC/STDN Data Flow Test Summary 
(Total of 55 Teats, Period 3/28/78 to 5/11/78) 
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Test Legend: 

A - PRT (DDPS/SCE) with simulator data 

3 * RT pass* simulator data* SCE 1* pre- and post -pass equipment delay measurement s of 00123 and 00456 
C - RT pass* actual spacecraft data (from analog tape); SCE 2, make journal tape for teat E, pre- and post-puss 
equipment del aye of 00100 

D - Post-pas* playback of RT pa»b from analog tap** using tape time track 

E - Post-pass playback of RT data from Journal tape (from teat C to simulate POGC missing data from a time 
correlation pass) 

S - Successful 

* Tent a C&D analog tape had many dropoutH. time to run K 
** Bad time tags 

*** Unsuccessful in receiving pood data for U&E 

**»»iest May 22-26 


Table 2-6. DDPS Phase I, Program 2, POCC/STDN Data Flow Test Summary 

(Period 5/2/78 to 5/11/78) 


Teat Function Checked 


No. 

of 

Sta Tests 

U1 

U2 

U3 

U4 

U5 

U6 

U7 

GCF. 
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SCE 
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DDPS 
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ting 

Time- 

Tag 

Accuracy 
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Equipment 
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SAR 

Demodulation 
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S 

N/A 
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S 
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Test Legend: 


U1 - PRT (DDPS/SCE) with simulator 

U2 - RT pass* simulator data* SCE 1, pre- and post-pass equipment delay measurements ot 00123 and 00456 

U3 - RT pass, actual spacecraft data (from analog tape); SCE 2, pre- and post-pass equipment delays of 00100 

U4 - Post-pass playback of RT pass (25 kb/s) from analog tape using tape time 

U5 - RT pass with 25-kb/s RT and 800-kb/s dump using actual spacecraft data from analog tape 

U6 - 800-kb/s dump past pass playback from analog tape using tape time (TEL0PS/FN0C only) 

U7 - RT (25-kb/s) data* via 56-kb/s link (simulates unavailability of 1.544-Mb/s link) 

S - Successful 
* Bad time tags 
**No change to test 
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The POST also participated In the POS test and training plan activities 
described in Section II-D of this report. GSFC POCC Operational Readiness and 
Performance Assurance (ORPA) meetings were, held regularly from 26 January 1978 
through the end of the mission. Representatives attended from all groups with 
responsibilities in the POCC. The ORPA POCC deficiency and enhancement request 
system was used to track software and hardware problems and enhancement requests. 

Schedules. POST support was provided on a schedule that was compatible 
with project requirements. 


3. Command Management System 

a. Requirements . The CMS at GSFC was responsible for the management of 
memory commanding for the Seasat mission. The CMS received mission planning 
information from JPL through the POCC, and translated it into memory loads that 
were transmitted to the POCC for subsequent loading on the Seasat onboard 
memories. 

Specifically, the requirements for the CMS were to: 

(1) Provide an interface to accept and edit all inputs of stored 
command requests. 

(2) Merge all current, pending, and automatic command requests Into a 
single GMT-ordered list. 

(3) Determine memory loads in size, time span, and loadability. 

(4) Fabricate spacecraft commands from the command requests into 
acceptable spacecraft memory load format for transmission to the 
POCC. 

(5) Check for constraii c violations. 

(6) Provide with each memory load an English command/orbital event 
description in a GMT-ordered list. 


The CMS was developed for the IBM S/360-65 computer at GSFC with an IBM S/360-95 
as backup. 


b. Implementation . The CMS software system was developed by Computer 
Sciences Corporation under the direction of GSFC Code 514. Figure 2-7 shows 
the data ' iterfaces and processing steps involved. 

No significant problems were encountered in the development and implemen- 
tation of the Seasat CMS. Processing specifications were provided in the 
project’s SIRD; data interfaces were defined in the ICDs, and operational con- 
siderations were coordinated in planning meetings held both at JPL and GSFC. 
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Figure 2-7. CMS Interfaces and Processing 











c. Testing. Seasat CMS proof tests were conducted at two levels: 
software acceptance tests and system operational tests. Software acceptance 
testing was conducted by the CMS operations contractors. Computer Sciences 
Technicolor Associates (CSTA). and consisted of verifying and demonstrating the 
basic CMS functions, i.e., project requirements. These tests were successfully 
conducted between February and May 1978. 

The CMS also supported a series of operational simulation tests conducted 
by the JPL MCT. These tests, conducted between March and June 1978, exercised 
CMS capabilities and Interfaces using planned mission sequences and timelines. 

All tests were successfully completed, and the CMS-generated products (loads, 
maps, and MSOEs) were delivered according to test schedules. 

Two minor problems were identified during system tests. These problems 
were the occasional failures of the CMS/POCC computer-to-computer (electrical) 
interface and extraneous print characters contained in the command load English 
descriptor. The transmission problems were not resolved, but presented no 
operational impact because of a backup tape interface capability. The extraneous 
print problem was corrected after launch by a minor software patch. 


d. Schedule . The Seasat CMS software was delivered in four phases 
evolving from a skeleton system in April 1977 to a final (full capabilities) 
system in March 1978. All deliveries were essentially on schedule, and the CMS 
was considered ready for mission support by 28 March. 

As previously stated, a software patch was delivered after launch 
(August 1978); however, the problem was considered to have no impact on mission 
operations, and the fix was delayed until after early mission activities. 


4. Orbit Determination System 

a. Requirements . The responsibilities of the orbital operations 
personnel were to: 

(1) Provide launch and early orbit determination. 

(2) Provide operational orbit support. 

(a) Provide predicted operational orbit computations with an 
accuracy of 20 km (11 nm) to project-designated recipients 
at the end of a 1-week period. 

(b) Provide orbital elements to FNOC, JPL, Smithsonian Astro- 
physical Observatory (SAO) , Oakhanger, Shoe Cove, and the 
user community. 

(3) Provide definitive orbit computations with an accuracy of 50 m 
(164 ft) along-track, 30 m (98 ft) cross-track, and 30 m radial 
to project-designated recipients. 
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(4) Process, format, and distribute S-band and laser tracking data. 

(5) Provide scheduling aids to project -designs ted recipients. 


b. Implementation . In resolving the above requirements. SIRD and MOP 
documents were used. ICDs were also established: (1) between Orbit Determina- 

tions and the POCC, and (2) between Orbit determinations and the IPD and JPL. 

In establishing these ICDs. a joint effort was made by the parties involved. 

Orbital computations were performed on the IBM 360 computer complex using 
the existing orbit determination system for other spacecraft. The programming 
changes required in the system were for generation of range tape required by the 
project to compute the clock offset. 

To meet the {•i.eviously mentioned accuracies of 50 m, 30 m, and 30 m, the 
support system used the appropriate force modeling, representation, station 
geodetics. and physical and environmental parameters. A close working relation- 
ship between the orbital operations support group and the networks was maintained 
to secure the appropriate distribution and amount of observational tracking data. 
The definitive orbital ephemerides were provided to IPD and Attitude Determination 
in the form of magnetic tape and in the time frame to meet the 6-day project 
package data delivery. 

Strict procedures were established for quality control on computations of 
this particular function. Processing of this definitive orbit determination data 
required the use of the IBM 360 computer on a daily basis for approximately 1.5 h, 
but, because of the fine individual efforts, this had little impact on other 
projects. 


c. Testing 

(1) Observational tracking data from the existing spacecraft (Landsat-1 
and GEOS-3) were processed to demonstrate that accuracies of 50 m, 

30 m, and 30 m in orbit computation could be achieved. However, this 
placed the following requirements on the project: 

(a) Project to provide 14 passes a day (one each orbit and at 
least one each station) of S-band Doppler data to orbit 
operations. 

(b) Project to provide seven passes a day, well geographically 
distributed, of S-band range data to orbit operations. 

(2) Predicted range tapes to be provided to the POCC to determine if the 
tape was properly formatted. 

(3) Predicted definitive orbit data to be provided to IPD and JPL. 
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(4) Telety,> orbital elements to be provided to JPL, FNOC, UKO, and SNF. 
No testing was required to transmit the orbital elements to SAO and 
Sunnyvale* as these Interfaces were already in use for other 
spacecraft. 

d. Schedules. All schedules were met on time. 


5. Attitude Determination System (ADS) 

a. Requirements . The ADS support by GSFC consisted of determination of 
three primary functions under the direction of the attitude computations analyst. 
For this mission* there were three distinct attitude determination functions: 
real time, quick-look* and definitive. In satisfying all three requirements* 
telemetry data from the two Ithaco infrared horizon sensors and the four Adcole 
sun sensors were the primary method for determining attitude. 

The specific requirements were: 

(1) Real Time . For each station contact to compute yaw from the 
satellite sun sensor data, to extract, calibrate, and display pitch 
and roll, and to compute solar panel tracking error data. 

(2) Quick-Look Attitude Determination . To compute whole orbit yaw data 
as accurately as possible and provide to the satellite analysis team: 
(a) nine orbits (maximum 30 percent) during the first 2 weeks after 
launch, and (b) two to four orbits for each orbit maneuver or adjust, 
with a turnaround time requirement of ''near-real time." 

(3) Definitive Attitude Determination . To provide continuous pitch, 
roll, and yaw attitude to 0.17 deg (3 sigma) for each axis, to be 
generated daily and to span the same satellite data day as the con- 
cents of the PMDF. 

The Definitive Attitude File (DAF) contained time-tagged attitude 
data points at a frequency high enough to cause less than 0.02-deg 
linear interpolation error per axis, but within the period range of 
5 to 60 s. The DAF was to be generated in time to meet the overall 
6-day project data package. 

(4) A secondary ADS requirement was to support the LMSC attitude simulator 
software programs. These requirements were to obtain the results of 
whole orbit yaw attitude data in engineering units and run on a 
general purpose IBM 360 computer. 


b. Implementation . Real-time attitude determination was defined as the 
on-line processing and displaying of attitude parameters as the real-time data 
were being received from the tracking station. Attitude determination in real 
time was performed only in the Seasat POCC on the Sigma 5 computer, upon option, 
using all real-time data received throughout all phases of the mission. In 
computing attitude, the POCC used only real-time data that had been transmitted 



from the tracking station using a high-speed data link through NASCOM 
(Figure 2-8). The POCC stripped and calibrated real-time pitch and roll data 
directly from the spacecraft, and optionally adjusted each observation by a 
fixed bias. Following this judgment, the pitch and roll angles were displayed 
on a CRT display. The yaw angle was computed only when sun sensor data were 
available, as follows. 

Solar ephemeris and predicted spacecraft ephemeris, from an orbit EPHEM 
tape, was used weekly to generate and store the predicted sun unit vector in the 
orbital coordinate system on the hour for 1 week. These stored data and the 
telemetered sun sensor and scanner data were used to compute yaw in the Geocentric 
Inertial Coordinate (GIC) system at selected intervals upon request. Because this 
computation was performed asynchronously with the real-time processing, it was 
done using available cycle time and, consequently, computed and displayed a yaw 
attitude approximately every 30 s. Out-of-limit conditions for pitch, roll, and 
yaw were also flagged and displayed on the CRT. The observed minus predicted 
solar panel tracking angle error were also computed and displayed in real time. 

It ' led as input the same stored sun information in the orbit coordinate system 
as was used for yaw computations, in addition to the solar panel tracking angle 
from telemetry. The computation of this value was also done in an asynchronous 
mode using available cycle time. There was no accuracy requirement or commitment 
for real-time processing of pitch, roll, yaw, and solar panel tracking angles. 

Quick-look attitude determination was the processing of whole orbit 
(playback tape recorder) telemetry data for attitude solutions on an as-soon-as- 
possible basis (nominally 6 h after receipt at GSFC), Quick-look data were 
processed using the definitive attitude determination system on one of the 
IBM S/360-75 (Cl), -75 (C2) , and -95 (backup) computers, configured as illustrated 
in Figure 2-9. The processing was done during the first 2 to 4 weeks of the 
mission to support the attitude control system and orbit adjustment, and sub- 
sequently to support orbit trim maneuvers that were expected to occur once a 
month throughout the mission. During this period, up to four playback passes 
(100 min each) of selected data a day were sent directly from the station to the 
IPD. The TPD reversed the telemetry bit stream to chronologically order the 
data and send it to the POCC via a hand carried magnetic tape (illustrated by the 
dashed lines in Figure 2-8). The tape was played through the POCC software 
between real-time contacts where the attitude-related information was stripped 
and sent via a 9.6-kb/s analog data link (ADL) to the quick-look processing 
area. There the data were stored on disks and accessed by the definitive atti- 
tude determination software to compute pitch, roll, and yaw when valid sun 
sensor data were available. 

Hard copy plots of pitch, roLl, and yaw were hand-carried to the POCC for 
each playback pass processed, and an attitude results data set was generated on 
a sharable disk for access by the LMSC parameter estimation program. These 
programs were used to trim the spacecraft control parameters to maintain the 
spacecraft attitude within its specified control limits. The attitude plots were 
also used by the POCC to determine when the switch from gyro control to wheel 
control could take place following the orbit adjustment and orbit trim maneuvers. 

A detailed attitude data flow diagram is provided in Figure 2-10. 































Definitive attitude determination was defined as after-the-fact processing 
of attitude telemetry data using a determined (definitive, as opposed to pre- 
dicted) orbit ephemerls to produce a continuous time history of the spacecraft 
attitude. For the Seaaat mission, definitive attitude processing was accomplished 
using the IBM S/360-95 computer with the -75 Cl serving as a backup (Figures 2-9 
and 2-10). The definitive attitude determination activity was initiated immed- 
iately following the spacecraft universal time corrected (UTC) correlation update 
and was continued for the duration of the mission. All playback and real-time 
data received at the tracking station were transmitted by hard line through 
NASCOM to the 1PD. The IPD then checked the data, created a time history of 
the telemetry data, and packaged it in 24-h blocks. These data began at 0000 h 
of spacecraft clock time, which was maintained to within 200 us of UTC, and 
ended at 2400 h of spacecraft clock time. 

These 24-h blocks minus and plus one orbit of data (100 min, for yaw inter- 
polation only) was sent daily to the definitive attitude processing area. There 
the data were validated and adjusted for timing, oblateness, and horizon radiance 
errors. The data were then processed using the sun and definitive orbit ephemer- 
ides to compute pitch and roll angles for all times that there were valid tele- 
metry information and yaw angle when valid sun sensor data were available. 

Yaw attitude results for all other times were provided by an attitude inter- 
polation and extrapolation algorithm developed by JPL personnel, which was backed 
up by an algorithm that filled in data with a constant value for yaw. JPL had 
complete responsibility for providing the values of all parameters that character- 
ized the yaw interpolation algorithm. Attitude data during small telemetry gaps 
(whose length was dependent on spacecraft attitude rates) were filled in by 
interpolation with the attitude data smoothing algorithms. 

"he raw telemetry data package received from the IPD covered 0000 to 2400 h 
of spacecraft clock time, and the attitude results for the spacecraft were pack- 
aged to cover the corresponding UTC. These results were included in the IPD 
6-day project data package. A timeline for Seasat definitive attitude data 
processing is presented in Figure 2-11. Telemetry data and definitive orbit data 
were normally received in the attitude processing area 2 to 3 days after the data 
were receive 1 at the ground station. Attitude results were usually returned to 
IPD within 1 to 2 days after the receipt of both the orbit and telemetry data. 

Any additional data received for a given collection day after the initial data 
had been processed were treated as a separate entity and were output as an entity. 

The goal of the attitude determination processing was 0.17 deg (3c) for 
pitch, roll, and yaw. Definitive attitude results were not required during 
spacecraft orbit adjust periods or when the satellite was being maneuvered to 
non-nominal attitudes (pitch, roll, or yaw angles greater than 10 deg in 

magnitude) . 

Because the satellite hardware operated in a backup mode of attitude con- 
trol and the configuration changed throughout most of the mission, an estimate 
of the actual accuracy achieved is not possible. 
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c. Tests and Interface Checks . A complete end-to-end attitude test of 
the ADS was not possible without having actual satellite data available in a 
flight configuration. Therefore, simulated data streams were generated and their 
output followed and verified v roughout the system. Table 2-7 contains a summary 
of the tests conducted by the ADS to verify the system. When a problem was 
encountered, a correction was made and a retest was performed. Additionally, 
retesting was performed for each new delivery of software within the system. 


Table 2-7. Tests and Interface Checks 


Real-Time Attitude 


Simulated telemetry tape to exercise and compare known results. 


(1) 

Pitch 

and 

(2) 

Sun ar 

igle 

(3) 

Check 

yaw 

(4) 

Check 

for 


roll stripping and conversion, 
stripping, conversion, and calculation, 
computation. 

solar panel tracking angle. 


Quick-Look Attitude 

(1) Simulated and real telemetry tapes run through POCC software to 
strip out attitude-related data and send through ADL to MAPS. 

(2) Hand-compare dumps of data input and output from POCC and received 
at AOS. 


(3) Compare attitude raw data and results between POCC and MAPS. 

(4) Exercise MAPS with attitude data simulator. 

(5) Check out backup attitude telemetry data tape. 

Definitive Attitude 


(1) Check for proper data stripping from IPD for MAPS by hand-using 
simulated and real telemetry tapes and dumps. 

(2) Use dummy attitude results tape for early check of MAPS/IPD/.1PL 
interface. 

(3) Exercise MAPS with attitude data simulator to exercise MAPS and 
MAPS /IPD/JPL interface. 

(4) Check out backup attitude telemetry and results magnetic tape to 
ensure that it is the same as that which comes aero s link. 
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d. Schedule. The schedule for the ADS Is shown In Figure 2-12. The 
schedule was implemented as planned or changed as Indicated in the notes at the 
bottom of the figure. 

6. Flight Maneuver Operations Center 

a. Requirements . The primary responsibility of the GSFC Flight Maneuver 
Operations Center (FMOC) was to aid the JPL MCT in the prediction) planning, and 
evaluation of Seasat orbit maneuvers. Specifically, the requirements were to: 

(1) Evaluate the post-injection orbit and plan maneuvers to remove 
injection errors. 

(2) Perform the post-maneuver analysis required to calibrate the onboard 
thruster system. 

(3) Provide maneuver requirements predictions based on an analysis of the 
ground trace history. 

(4) Design maneuver events (thrust magnitude and times) to achieve the 
desired target parameters. 


b. Implementation . No major problems were encountered in FMOC imple- 
mentation (Figure 2-13). "Considerable pre-launch coordination was conducted in 
planning meetings attended by mission personnel from JPL, GSFC, and LMSC. Maneu- 
ver interfaces were defined, and a timeline was developed for maneuver planning, 
execution, and evaluation. The FMOC software developed for Seasat comprised an 
evolutionary maneuver model augmented with Seasat-peculiar physical and perform- 
ance data. Vehicle information was provided by LMSC, and software development 
was performed under contract to GSFC by Computer Sciences Corporation. 


c. Testing . FMOC system acceptance tests (functional proof tests) were 
successfully conducted between November 1977 and February 1978. The FMOC also 
participated in four maneuver simulations between April and June 1978. Each of 
these simulations assumed a set of current as opposed to desired orbit conditions. 
The maneuvers were then designed, executed, and evaluated according to the mis- 
sion procedures and timeline. The simulations proved to be beneficial, and 
maneuver responsibilities and interfaces were well defined. 


d. Schedule . System development, test, and integration progressed 
according to schedule and the FMOC was ready for mission support by 1 May 1978. 
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Figure 2-12. Seasat Attitude Support Milestone Schedule 






7. 


Telemetry On-Line Processing System/IPD 


a. Requirements . Specific requirements for the Telemetry On-Line 
Processing System (TELOPS) and the IPD were to: 

(1) Reverse the reversed playback telemetry data. 

(2) Remove overlap from the playback data. 

(3) Process data on a 1-day (24-h) basis. 

(4) Generate Project Master Data File (PMDF) . 

(5) Generate Data Accountability Log (DAL). 

(6) Strip attitude parameters from the PMDF and transmit to the attitude 
computation center. 

(7) Strip housekeeping data from PMDF for use by the POCC. 

(8) Receive attitude (ATT), orbit (ORB), and command (CMD) data from the 
respective organizations at the GSFC for Inclusion in the Project 
Data Package (PDP) . 

(9) Concatenate ATT and ORB data on a single tape. 

(a) Ensure that the attitude/orbit (A/0) tape contained an ATT 
and ORB file. 

(b) Tape check the A/0 ipe and generate a shipping letter. 

(10) Assemble and forward the PDP containing PMDF, ORB, ATT, and CMD data 
to JPL. 

(11) Ensure that tapes shipped to o.her users were copies of tapes shipped 
to JPL. 

(12) Archive only TMDF (playback telemetry data). 

(13) Ensure quick turnaround of quick-look data (one to two revolutions 
a day for the first 2 weeks after launch, then about once a month 
during orbit trim maneuvers and during low power periods). IPD to 
provide data to the POCC within 4 to 6 h of receipt at TELOPS. 

There was no requirement to process real-time data. 


b. Implementation . The overall playback data flow for Seasat is shown 
in Figure 2-14. Data were nominally processed in the production mode and, during 
launch and spacecraft critical periods, in the quick-look mode for the POCC. The 
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Figure 2-14. Overall Playback Data Flow 








quick-look mode was the rapid turnaround of data processed through the production 
cycle and provided to the POCC on a magnetic tape. 

Production data processing used Scasat telemetry data acquired at the STDNs. 
XPD provided the project with the complete coverage telemetry after receiving and 
processing the data from the STDNs. 

An A/O tape was also generated for each day of data processed. Attitude 
data were received from ADS through the data communications link between the 
Univac 1108 and IBM 360 computers. Orbit data were received by IPD on digital 
magnetic tape from the operational orbit support branch. Attitude data occupied 
the first file of A/O tape, and the orbit data occupied the second file. A 
computer printout containing spacecraft command data was also provided to IPD by 
the Seasat POCC. These three sets of data were packaged and shipped to JPL for 
additional processing by the Seasat Project. 

The Input Processor (IP) in the TELOPS environment was the IBM 370 computer. 
The IP received the telemetry data through NASCOM, appended transmission quality 
flags to each pass message, reversed the playback data, and performed data quality 
checks. These data were then stored in a mass storage system in the order the 
data were recorded from the spacecraft. 

The operations team in this area consisted of four people. They provided 
24-h, 7-day-a-week coverage. Four 6250 b/in. capability tape drives were added 
to the existing system, primarily due to the high rate Seasat telemetry, though 
not exclusively for Seasat. 

A spacecraft-unique software routine was developed for processing Seasat 
data. The telemetry data were edited by the Telemetry Data Processing System 
(TDPS), a program on the Univac 1108 computer. The TDPS edited the playback data 
from the TELOPS mass storage system. 

Prior to launch, two tape drives with 6250-b/in. capabilities were added to 
the existing system. This, again was not exclusively for Seasat, but because of 
the high-rate Seasat telemetry data. There were no special software developments 
for the Seasat mission. 


c. Testing . The major problem in testing the system was the lack of 
actual spacecraft data. Various interfaces were tested using the only available 
34-min data, which were recorded during the compatibility test. The following is 
a list of the interfaces that were checked: 

(1) IPD/Network 

(a) 56 kb/s. 

(b) 112 kb/s. 

(c) 224 kb/s. 

(d) 1.344 Mb/s. 
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(2) IPD/POCC. 

(a) High-speed keying (HSK) Cape Co POCC. 

(b) Command lisCing from POCC. 

(c) Time offsecs from POCC. 

(3) IPD/AcciCude. 

(a) Raw ATT Co MSC&AD. 

(b) DefiniCive ATT from MSC&AD. 

(4) IPD/OrbiC: 24-h orbic cape from OSCD. 

(5) IPD/JPL. 

(a) PMDF . 

(b) DAL. 

(c) A/0 tape. 

(d) Command lisCing. 

d. Schedules . Although most of the schedules were slipped, every item 
was completed by 26 May 1978 as mentioned in the launch review. 


8. NASA Communications Network 

The NASCOM provides all NASA mission control and network control centers 
with real-time operational communications to launch sites and remote tracking, 
data acquisition, and command stations. These communications are for pre-mission 
spacecraft launch checkout, mission and network simulations, operational support 
of launch, and Earth-orbital phases of missions. 

The NASCOM is an operational global communications system of diversely 
routed voice, low-speed data (teletype), and high-speed and wideband data commu- 
nications channels, with switch and technical control facilities linking approxi- 
mately 100 terminal stations. The NASCOM circuits are full-period channels, 
leased from various domestic and foreign common carriers on a worldwide basis. A 
variety of telegraph, voice, data (analog and digital, with a range of digital 
data rates), and television (TV) services are provided. For mission-unique 
requirements, temporary circuits are sometimes used to meet short-term 
requirements. 
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a. Requirements . The mission-unique requirements were to: 

(1) Upgrade the 56-kb/s data circuits to the stations. 

(2) Provide a 1,544-Mb/s data circuit between ULA, FNOC, and GSFC. 

(3) Supply multiple 56-kb/s data circuits between MAD-GSFC. 

(4) Supply a 224-kb/s data circuit between MIL-GSFC and GSFC-FNOC. 

(5) Supply a new 3760 computerized message switcher at GSFC f block error 
decoders (BEDs) at JPL and FNOC, and new contractor Earth stations 

at MIL and GSFC to support the 224-kb/s data circuits. These require- 
ments are shown in Figure 2-15. 


b. Implementation . The requirements were implemented on schedule, as 
follows: 

(1) A simplex 1.544-Mb/s wideband data service was provided from ULA with 
a simultaneous transmit capability to FNOC and to GSFC. This system 
was used to transmit the 800-kb/s playback telemetry data to FNOC 

and to GSFC IPD/TELOPS and the 25-kb/s real-time telemetry data to 
the Sea sat POCC at GSFC. 

(2) The Department of Defense (DoD) reruired the FNOC to receive space- 
craft playback data that was downlinked at a station other than ULA. 
This was accomplished, when scheduling permitted, by using a 224-kb/s 
service between MIL and GSFC, and another 224-kb/s service between 
GSFC and FNOC. This playback data transmission was speed-reduced to 
fit the circuit, and the data blocks were message-switched at GSFC 

to FNOC. Two 56-kb/s wideband data circuits were linked together 
from MAD to GSFC to provide a 112-kb/s capability. The playback data 
transmission was also speed-reduced to fit the circuit, and the data 
blocks were message-switched at GSFC and transmitted to FNOC over the 
224-kb/s wideband data circuit. 

(3) An existing 7.2-kb/s circuit was used to transmit spacecraft command- 
related data from the JPL Mission Support Area (MSA) to the Seasat 
POCC at GSFC. These data were retransmitted to the GFSC CMS on a 
local GSFC 9.6-kb/s circuit for the production of a Mission Sequence 
of Events (MSOE). The MSOE was transmitted by a 9.6-kb/s circuit to 
the Seasat POCC for subsequent retransmission to the JPL MSA via a 
7.2-kb/s circuit. 

(4) The spacecraft checkout tests at LMSC were supported by a 56-kb/s 
wideband circuit (full duplex) routed via JPL to GSFC. This circuit 
was used to transmit commands from the Seasat POCC at GSFC to the 
Seasat spacecraft, and to transmit spacecraft data to the POCC. A 
voice circuit was also provided for coordination purposes. Playback 
data (800 kb/s) were transmitted at a reduced rate from LMSC to the 
GSFC IPD/TELOPS. 
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(5) A simplex 50-kb/s wideband circuit routed via JPL to GSFC was provided 
to transmit spacecraft and Agena data from the Space and Missile Test 
Center (SAMTEC) Western Test Range to the Seasat POCC at GSFC. Exist- 
ing high-speed data, voice, and teletype circuits were used to provide 
the necessary launch support. 

(6) The wideband systems digital facilities were implemented in a variety 
of ways, depending on locations, overseas considerations, and the 
carriers concerned. Overseas channels were implemented via communi- 
cation satellite systems that included Earth stations of the foreign 
and domestic Intelsat. Foreign end-segments were implemented using 
terrestrial and domestic satellite facilities of the Bell System and 
other specialized communication carriers. 


c. Tests . Three types of tests are usually performed on NASCOM equipment, 
The supporting contractors from whom NASA leases the circuits are responsible for 
conducting tests before NASA acceptance. These test data are then reverified to 
the extent necessary by NASCOM engineers. Operational testing is then performed 
in conjunction with the POCC and STDN testing program to ensure that configura- 
tions and equipment performed with actual data as required. 


d. Schedule . The schedule is shown in Figures 2-16 and 2-17. 


9. Space Flight Tracking and Data Network 

GSFC Networks Directorate support to the Seasat Program began in calendar 
year (CY) 1973 during Phase A studies for a Seasat mission as part of NASA’s 
Earth and Ocean Applications Program. Support continued through an implementation 
period from approximately November 1975 to April 1978, and was concluded in the 
fourth quarter of 1978. Support ended as a result of a spacecraft power system 
failure approximately 3-1/2 months after launch. Included in the following para- 
graphs are descriptions of STDN support throughout the three periods, emphasizing 
new and applied capabilities developed for Seasat mission support. 


a. Study Phase . The network input to this phase of the program consisted 
of providing STDN cost estimates and expected capabilities, station locations, 
antenna characteristics, cornu unicat ions performance data, etc., to the project 
organization preparing trade-off studies, and ultimately the Mission Specifica- 
tion document. Following contract award (fourth quarter of CY 75), fact-finding 
activities were supported to ensure that the satellite systems would be compatible 
with the STDN, for conventional tracking, telemetry, and command functions and 
for design of the SAR telemetry and ground support systems (which required signi- 
ficant development work). 
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Figure 2-17. SAR Support Implementation Schedule 


b. Implementation Phage . STDN support during the implementation phase 
is described in the following paragraphs on a data and support system basis. 


Command System. During the period fiom the fourth quarter of CY 75 to the 
second quarter of CY 76, the project determined that the "standard" command 
detector unit (14-kHz subcarrier, PCM/FSK-AM/PM) , also planned to be flown on 
the SAGE and 1SEE missions, was confirmed to be compatible by design, and was 
selected by the project to be flown on the Seasat mission. Design link calcula- 
tions were confirmed by the network to be compatible. The STDN Implementation 
for providing command system support and pre-launch test support periods are 
shown in Figure 2-18. 

The only command system implementation problem disclosed by pre-mission 
testing systems review was a demonstrated inability of station SAR telemetry 
control equipment to account for the time-of-day crossover for pass loads con- 
taining equipment settings for acquisition of signal (AOS) during 1 day of the 
year and loss of signal (LOS) on a succeeding day of the year. A one-wire modi- 
fication to the SAR station equipment (which, incidentally, removed time regres- 
sion error compensation circuits in a pass load) corrected the problem. 

The STDN command software was initially developed in August 1977 with 
anticipated use during a planned October 1977 spacecraft /network radio frequency 
(RF) compatibility test. The test slipped to November 1977 and had to be aborted 
because of spacecraft system problems. Tables 2-8 and 2-9 are listings of soft- 
ware support instructions (SSI) issued during the Seasat support period. 


Table 2-8. STDN Software Support Instructions (SSI) 
Issued During Seasat Support Period 


tty 

SST Date/Time 
Month Year 


MSFTP 2 
Simulator 
TESOC 
557 S 


MSFTP- 3 
Decomm 
TESOC 
590 MD 


MSFTP- 3 

TESOC 
557 MD 


MSFTP-3 4 8 IDF (A) 481DF (A) 

TESOC TESOC TESOC 

557.1 MD 557 DG 2004. 1 SC 


Level Errata Level Errata Level Errata Level Errata Level Errata Level Errata 


061 

23/2320Z 
Aug 1978 



(B) 

Mil. 

only 

06^ 

10/1520Z 
Sep 1978 




063 

08/1056Z 
Sep 1978 




064 

24/0026Z 
Oct 1978 




065 

28/0451Z 
Oct 1978 

(B) 

(A) 

(B) 



Figure 2-18. STDN Command System Support for Seasat 





Tabic 2*9. STDN Telemetry Processing Software Support Instructions (SSI) 
Issued During Seasat Support Period 


Digital Data Procaaaing System 


Prograa 2 Prograa 3 

TTY 

... Data/Tlaa 642 642 (CP) PDP-11 PDP-11 PDP-11 

Month Year SIC 9999-<l) SIC 9999- (L)CP SIC 9999-(L)DP SIC 9999-(L)TP SIC 9999-(L)PP 
(CCEN) SCAN 6-700.1 SCAN 6-703 SCAN 11-703 SCAN 11-703 SCAN 11-703 




Level Errete 

Level 

Errata 

Laval 

Errata 

Level 

Errata 

Laval 

Errata 

050 

10/2303Z 
Jan 78 

- 

- 

- 

- 

- 

- 

- 

- 

- 

051 

20/18112 
Jan 78 

- 

- 

- 

- 

- 

- 

- 

- 

- 

052 

08/S 930Z 
Fab 78 

- 

- 

- 

- 

- 

m 

- 

- 

- 

053 

23/2155Z 
Fab 78 

4-DD 414-419 
(Testing Only) 

- 

- 

- 

- 

- 

- 

- 

- 

054 

06/2313Z 
Apr 78 

$-DD 14-19. 
22, 23, 
99 

(Testing Only) 








— 

055 

07/1955Z 
Apr 78 

4-DD 14-19, 
22, 23, 
99 

(Testing Only) 








— 

056 

19/1520Z 
Apr 78 

4-DD 14-19, 
22, 23, 
99 

(Tasting Only) 
(HCCM Ops Spt) 











4-DE 

(Seasat Tast 
Spt) 









057 

02/1841Z 
May 78 

4-DD 14-19, 
22, 23, 
99 

(HCCM Ops Spt) 







** 

— 



4-DE 

(Seasat Test 
Spt) 









058 

11/1525Z 
May 78 

4-DD 14-19, 
22, 23, 
99 

(HCCM Ops Spt) 








— 



4-DE 001 

(Centaur) 
(Seasat Test 
Spt) 










Table 2-9 


STDN Tclauatry Processing Software Support Inatructiona (SSI) 
Iaauad During Saaaat Support Period (Continuation 1) 




Digital Data Procaaaing Syataa 


m 

... Data/Tlau 
581 Month Yaar 
(CCEN) 

Prograa 2 


Progri 

Ml 3 


642 

SIC 9999- (L) 
SCAM 6-700.1 

642 (CP) 
SIC 9999- (L)CP 
SCAN 6-703 

PDP-11 

SIC 9999- (L)DP 
SCAN 11-703 

PDP-11 

SIC 9999- (L)TP 
SCAN 11-703 

PDP-11 

SIC 9999- (DPP 
SCAN 11-703 


Laval Errata 

Level Errata 

Laval Errata 

Level Errata 

Level Errata 


059 18/0626 
May 78 


060 26/11 15Z 
May 78 


061 02/01 17Z 

May 78 


062 08/0407Z 

Jun 78 


063 12/OUSZ 
Jul 78 


064 25/2216Z 

Jul 78 


♦-DD 14-19* 
22* 23* 
99 

(HCm Ops Spt) 

$-DB 001 

(Seasat Test 

Spt) 

♦-DD 14-19, 
22, 23, 
99 

(HCMM Ops Spt) 

$-DE 001 
(Stasat Test 
Spt) 


4 -DO 


14-19, 
22, 23 
99 


(HCMM Opa Spt) 

4-DE 

001 

(Seasat Test 

Spt) 


♦-DE 

1-6 

(Seasat Test 

Spt) 


<)-DE 

1-7 

MIL: 

1-7,9 

(Seasat Ops 

Spt) 


t-DE 

1-7 

MIL: 

1-7,9 

(Seasat Ops 

Spt) 



None $6 None 
(Seasat ULA Test Spt) 


None $6 None 

(Seasat ULA Test Spt) 

None $6 None 

(Seasat ULA Test Spt) 
None 06DP 04 


06TP 13, 80, 06FP 00 
81 


None 


Seasat Test Spt - 

06DP 04 06TP 


13* 80, 
81 


06FP 00 


’ Seasat Test Spt — 
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Table 2-9. STDN Telemetry Processing Software Support Instructions (SSI) 
Issued During Seasat Support Period (Continuation 2) 


Digital Data Processing System 


TTY 

Date/Tine 
Month Year 
(GCEN) 


Program 2 


Program 3 


642 

SIC 9999- (L) 
SCAN 6-700.1 

642 (CP) 

SIC 9999- (L) CP 
SCAN 6-703 

PDP-11 

SIC 9999-(L)DP 
SCAN 11-703 

PDP-11 

SIC 5999-(L)TP 
SCAN 11-703 

PDP-11 

SIC 9999-(L)FP 
SCAN 11-703 

Level Errata 

Level Errata 

Level Errata 

Level Errata 

Level Errata 


<M>E 1-7 
MIL 
ETC: 
1-7,9 

(Seasat Ops 
Spt) 


06DP 04 06TP 19, 30, 06FP 00 

81 


Seasat Ops Spt 


12/0258Z 
Aug 78 


24/1445Z 
Aug 78 


068 02/10432 

Sep 78 





A 

A 



l-CP 

None 

07DP 

07DP 

07DP 




Flow Test Sr>f 


1-7 


Manual 

A 

A 


MIL 

1CP 

Patch 

07DP 

07DP 

07DP 

ETC: 


for 




1-7,9 


Nimbus 




Errata 



A 

A 


9 is 






for 224 






KBS 






COMMl/F 






1-7 

1CP 

Manual 

07DP 

07TP 

07FP 

MIL 


Patch 




STC: 


for 




1-7,9 


Nimbus 




Errata 



A 

* 

* 

9 Is 






for 224 






KBS 






CCMMi/F 






1-7.9 


32-34 

07DP 

07TP 

07FP 


1CP 


A 

* 

* 


^Although identified as level 7 in SSI’s 65-69, the program was actually a debugged and 
reissued level 6 



069 05/1752Z 
Sep 78 


♦-DE 1-7,9 


07TP 


07FP 


1CP 32, 33, 07DP 
34 

Manual * 

Patch 
Cor 

Nimbus 

070 08/0050Z $-DE 1-7,9 1CP 32, 33, 06DP - 06TP 24-29 06FP 

I Sep 78 34 

I Manual 

Patch 
for 

Nimbus 

071 29/0038Z *-nE 1-7,9, ICP 32-34 06DP - 06TP 24-29 06TP 

Sep 78 11. 12, 

17. 18, 

19, 21, 

24 

(-10 
Head B 
Teat 
Goa) 

072 14/0013Z 4>-DE 1-7, 9, ICP 32-34 06DP - 06TP 24-29 06FP 

Oct 78 11. 12. 

17, 18. 

19, 21, 

24 

(-10 
Head B 
Test 
Gos) 


*A1 though identified as level 7 in SSI's 63-69, the program was actually a debugged and 
reissued level 6 




Table 2-9. STDN Telemetry Processing Software Support Instructions (SSI) 
Issued During Seasat Support Period (Continuation 4) 


Digital Data Processing System 




Program 2 


Program 3 


SSI 

TTY 

Date/Time 
Month Year 
(GCEN) 

642 

SIC 9999- (L) 
SCAN 6-700.1 

642 (CP) 

^IC 9999- (L)CP 
SCAN 6-703 

PDP-11 

SIC 9999-(L)DP 
SCAN 11-703 

PDP- 1 1 

SIC 9999- (L) TP 
SCAN 11-703 

PDP-11 

SIC 9999-(L)FP 
SCAN 11-703 


Level Errata 

Level Errata 

Level Errata 

Level Errata 

Level Errata 

073 

01/1856Z 
Nov 78 

$-DE 1-7, 

9-12, 
17-19, 
21, 24, 
32 (35 
still 
tape 
test) 

1CP 32-34 

06DP 

06TP 24-29 

06FP 

074 

10/0355Z 
Nov 76 

4>-DE 1-7, 

9-12, 
17-19, 
21, 23, 
24, 32, 
35 

Delta 

Patch 

ICP 32-34 

06DP 

06TP 24-29 

06FB 

075 

07/1000Z 
Dec 78 

$-DE 1-7, 

9-12, 

ICP 32-34 

06DP 

06TP 24-29 

06FP 


17-19, 
21, 23, 
24, 32, 
33, 35, 
39 

Delta 

LV 

Manual 

Patch 
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10. LMSC Programs Developed for Seasat 

a. Power Program 

Development . The power program for the Seasat mission was initially 
developed during the proposal phase to be used as a design tool for determining 
solar array panel requirements. The program was modified after the Critical 
Design Review (CDR) to more accurately calculate power availability based on 
intra-revolution integration and K1/K2 status monitoring. Modifications continued 
throughout Seasat's lifetime and beyond. The program was used extensively for 
in-flight operations support. 


Background . The initial version of the program used routines developed for 
orbit average power, shadowing effects, beta angle calculations, and solar 
ephemeris used on other programs. This version also Included degradation effects 
from Palo Alto Laboratories. 

The orbit average power calculation was replaced by an integration routine 
(and improved battery modeling) based on work performed by the central power 
group . 


Checkout and Implementation . The power program was initially checked by 
comparison with other analytical techniques. In-flight calibration was performed 
and run on GSFC 360-75 computers for flight support. 


Purpose . The purpose of the power program was to provide solar array 
design analysis and to provide in-flight power system capability. 


Results . Flight experience has shown that the program was accurate to 
better than 51 percent (telemetry data uncertainty). 


b. Computer Programs for Attitude Control System Trim 

Development . These programs were developed before launch to be applied on 
activation of the Orbital Attitude Control System (OACS), using full orbit data 
from onboard recorders. Subsequent trim updates were scheduled once each month, 
if necessary. 


Background . The perturbation method for parameter estimation was used 
successfully on these programs and adapted to the Seasat configuration and 
requirements. Newly developed improvements were derived from recent works on 
estimation applications. 
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Implementation . The programs were implemented on GSFC computers and were 
tested using simulated flight data. 


Purpose . These programs were required for trim adjustment of control system 
parameters not accurately known before on-orbit observation, such as residual 
magnetic momenta and electromagnetic torque compensation gains. 


Results . Flight results demonstrated the pointing accuracy improvement 
from errors of about 6 deg before trim to about 1 deg after trim. 


11. Air Force Western Test Range 

The Seasat launch vehicle integration and launch support activities were 
supported by the Space and Missiles System Organization (SAMSO) using the 6595th 
Space Test Group (STG) and the Space and Missile Test Center (SAMTEC) at 
Vandenberg Air Force Base (VAFB) and the Kennedy Space Center /Western Launch 
Operations Division (KSC/WLOD). The project requirements at VAFB were directed 
through the 6595th STG with Air Force Western Test Range (AFWTR) implementation 
and operations responsibility conducted by the SAMTEC organization. The project 
support facilities and the satellite command and telemetry data handling and 
processing resources were provided through KSC/WLOD. 


a. Ground Data System Requirements . The Ground Data System (GDS) 
requirements for Seasat support at AFWTR were identified in the Program Require- 
ments Document (PRD) and are listed below: 

(1) Command . 2106.4 MHz PCM/PSK, AM/PM data link from the LMSC System 

Test Data System (STDS) Test Van 1 to the Agena vehicle at Space 

Launch Complex (SLC-3W) , pre-launch. 

(2) Telemetry . 

(a) Link 43 at 2243.5 MHz with 19 subcarriers. 

(b) Link 87 at 2287.5 MHz, PCM/Bi-<{>-LA oX/PM with 25 KHz on a 
1.6-MHz subcarrier. 

(c) Link 87 at 2287.5 MHz, PCM/Bi-4>-L/PM with 800 kHz on 1.6-MHz 
subcarrier . 

(d) Real-time Link 87, frame-synchronized 25-kb/s formatted for 
wideband transmission to POCC at GSFC. 

(e) Link 43 required for pre-launch through launch vehicle 
separation. 

(f) Link 87 required for pre-launch through ascent phase, inc'uding 
Agena first and second burns. 
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(3) 


Tracking . 


(a) Radar skin cracking with data processing Co produce posicion 
and velocicy scace vecCors wich Cransmission Co GSFC. 

(b) Launch vehicle guidance compuCaCion wich sacellice posicion and 
velocicy guidance state vecCors aC separaCion provided Co 

LMSC crajecCory aC Sunnyvale, California. 

(4) NASCOM Communicacions . 

(a) 50 kb/s wideband daca circuit for real-time Celemetry from KSC/ 
WI.01) to ”0CC at GSFC. (56 kb/s was required, but carrier could 
not implement in time; therefore, 50 kb/s was accepted.) 

(b) 2.4 kb/s high-speed data circuit for radar tracking data from 
VAFB tracking data processor to Goddard Real-Time System (CRTS) 
at GSFC. 

(c) One voice circuit for each of the following: 

Radar tracking data coordination. 

Range countdown. 

Mission operation circuit, VAFB to POCC. 

Mission directors circuit, VAFB to POCC. 

Telemetry coordination, KSC/WLOD to POCC. 

SPAT analysis, KSC/WLOD to POCC. 

Mission advisers, VAFB to JPL/GSFC/LMSC at Sunnyvale. 

Satellite manager to satellite analyst. 

ARIA data coordination at KSC/WLOD. 

(5) Teletype . 

(a) One standard GSFC to KSC/WLOD administrative. 

(b) One state vector information VAFB to ETR via DoD circuit with 
NASCOM extension hardwired at ETR /GSFC to GRTS room at GSFC. 


b. Launch Test Working Group . The Launch Test Working Group (l.TWG) was 
convened in early 1977 to function as the forum for placing requirements, moni- 
toring the status of implementation, and resolving problems. A subgroup of the 
LTWG was the Range Requirements Working Group (RRWG) , whose purpose was to 
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Interact on GDS requirements and agree on the needed range configuration to meet 
stated requirements. The actual support configuration used for Seasat is shown 
in Figure 2-19. The details of the GDS requirements stated above were defined in 
the WTR Operations Requirement document generated by the 6595th STG. The actual 
Implementation was responded to in the WTR Operations Directive generated by 
SAMTEC. The RRWG activities began in October 1977 (approximately 8 months before 
launch) at the insistence of GDS engineering, as AFWTR normally would not begin 
this type of activity until 6 weeks before launch. 


c. Ground Data System Testing. By February 1978, an agreed-upon GDS 
test plan had been published that established prerequisites that had to be com- 
pleted before an end-to-end ground data system test could be conducted to demon- 
strate GDS readiness to support both satellite system checkout activities and 
POS tests and training activities. Because SAMTEC considered their capabilities 
to be standard and multimission, the range did not include any operational test 
and training in their activities. Agreement was reached so that appropriate 
range resources would support satellite test and POS training activities. 

The established milestone dates were: (1) GDS demonstration test date was 

20 March 1978, and (2) combined POS test date was 5 April 1978. Both of these 
dates were slipped approximately 2 weeks because of the failure of NASCOM to 
implement the 50-kb/s wideband circuit by 1 March 1978, as required (actually 
available 31 March), nonavailability of the ARIA aircraft Marisat A satellite, 
and the delayed shipment of the Seasat satellite to VAFB. 

The GDS represented a very complex system with many organizational inter- 
faces. This complexity was not fully understood by all participants and resulted 
in not being able to achieve a successful demonstration of the two-satellite relay 
of 25-kb/s telemetry data in the time allocated. After four attempted system 
tests and several link tests, a decision was made to request the USAF Satellite 
Test Center at Sunnyvale to bring up the Indian Ocean Air Force Station at Mahe 
to record the telemetry downlink during the Agena second burn as a backup to the 
ARIA aircraft. This was done successfully. 

The KSC/WLOD support was excellent at all levels of requested support. 

Their flexibility and competence were key contributions to the successful support 
of the Seasat mission. 


12. Shoe Cove, Newfoundland Station Support 

The Government of C nnda has established an interdepartmental organization 
for the study of remote r sing systems. The program, designated Sursat for 
Surveillance Satellite, organized to examine a broad spectrum of remote-sensing 
systems with the objective of selecting a system or group of systems that are 
optimized to Canadian requirements. The Canadian involvement in the Seasat mis- 
sion was directed at acquiring a working knowledge of a spaceborne SAR. The 
following paragraphs outline the Canadian ground station implementation used for 
Seasat data acquisition at the Shoe Cove Satellite Receiving Station (SCSRS) 
located near St. John's, Newfoundland. 
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a. Requirements. The primary requirements of the SCSRS were to acquire 
and record SAR data for later processing by various experimentors. The specific 
station requirements are outlined below. 


S-Band and Pat* * Links 

(1) SAR Data Link . The Seasat wideband analog data link was unique in 
that it required specifically designed demodulators. Because the 
link required a 400-MHz intermediate frequency (IF) input to a NASA 
STDN Multifunction Receiver (MFR) , the SCSRS was modified accordingly. 
The Shoe Cove Landsat/NOAA acquisition system uses a 285- to 410-MHz 
IF for S-band; thus the front end of the downlink was modified. To 
do this, a separate S-band signal was split off the antenna monopulse 
sum channel, immediately following the parametric amplifier (Fig- 
ure 2-20) to permit the SAR data link to operate Independently of the 
tracking system. Because the existing Shoe Cove RF system is equipped 
for unified S-band (USB) reception, and because the USB link ip used 
for monopulse tracking, the tracking functions of an all-up MFR were 
not required. Therefor''}, a unique Seasat receiver was specified, 
providing the wideband AM detection functions required by the SAR 
coherent demodulator. 

(2) Seasat Telemetry Data Link . The station was requited to monitor 
several SAR engineering parameters during active SAR periods. To 
accomplish this, it was elected to monitor and record the complete 
low- rate telemetry (LRT) data stream carried on a 1.6-MHz subcarrier 
of the USB data link, so that a series of experiments using the low- 
rate sensors could be initiated. 


Digital Recording Subsystem . The station was required to record high- 
density digital tapes of SAR data. Because it was necessary for the station to 
be compatible with other stations, a SAR digitizer and high data rate recorder 
(HDRR) were selected that were identical to those used by the NASA STDN stations. 
The equipment was designed by the Applied Physics Laboratory (APL) of Johns 
Hopkins University. 

A minor modification of the APL system was required to permit playback of 
the HDRR tapes for the recording of analog signal film. This was a result of 
last-minute detail changes required by system interface requirements for the 
optical recorder system. 


Analog Recording System . The SCSRS system was required to record SAR data 
in analog form both photographically and magnetically. The photographic recorder 
recorded raw signals on film for subsequent optical processing. The magnetic 
recorder provided a reduced resolution image, which served as a backup for either 
the optical or digital recorder systems or both. Magnetic analog recording was 
originally intended to provide a method to acquire SAR data early in the program. 
This requirement decreased in importance when the spacecraft launch was delayed 
beyond May 1978. 

preceding page blank not 
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The film recorder recorded full bandwidth SAR signals, representing a com- 
plete radar swath of 100 km (54 nm) . The signal film was shipped to Ottawa 
where it was developed and optically processed by a Defense Research Establishment, 
Ottawa (DREO) laboratory. 

The magnetic analog recorder recorded a 12-MHz wide portion of the radar 
spectrum. The offset video signal was bandpass-filtered and frequency-translated 
to form two low-pass signals, each band-limited to 6 MHz. The two signals were 
recorded on a two-channel video recorder. On playback, the two low-pass signals 
were again frequency-translated, then combined to form a bandpass representation 
of the original offset video. 


b. Implementation 

Antenna RK System . The existing SCSRS antenna system was used to provide 
the front end for the Seasat system. The existing Landsat t’SB link was also 
used for both LRT acquisition and the antenna tracking loop. 

The antenna system comprised a 10-m prime focus parabolic reflector equipped 
with a single-channel monopulse feed. The feed operated at both 2200 and 2300 MHz 
and 1650 to 1750 MHz with optimization for the 2200- to 2300-MHz band. Antenna 
gain was 21 dB at 2250 MHz. The feed is shown schematically in Figure 2-20. The 
monopulse system at 2250 MHz comprised a 30-dB parametric amplifier fed from the 
sum channel antenna and a 30-dB transistor amplifier fed from the difference 
channel. The sum channel was then split by a power divider. One of the sum 
channels and one of the difference channels were combined in a 13-dB coupler to 
produce the amplitude modulation (AM) signal. This AM signal was then amplified 
by a 15-dB transistor amplifier before being applied by cable to the Landsat 
down-converter. The remaining sum channel was cabled to the Seasat down-converter. 

The Landsat down-converter operated with a local oscillator frequency of 
approximately 1918 MHz to produce a down-converted output at 285 to 385 MHz. 

This signal was then cabled through a multiplier to a Microdyne Model 1100 LS 
receiver. This receiver was tuned to 369 MHz to provide reception for the USB 
data link, and also provided an AM envelope detector for use with the antenna 
tracking loop. 

The Seasat down-converter operated with a local oscillator frequency of 
1800 MHz to produce an IF frequency of 400 to 500 MHz suitable for use with the 
Seasat receiver, because this data link was taken from the sum channel ahead of 
the tracking loop coupler, tracking AM was not present to cause interference 
with the operation of the MFR or Seasat receiver. The Seasat receiver output 
several signals to the SAR coherent demodulator, which was designed and con- 
structed by APL. 


Digital Data Acquisition System . SAR data were demodulated by the SAR 
coherent demodulator. This device output SAR data and control signals to the 
digital data acquisition system. The digital system was identical to that of the 
NASA STDN systems designed and constructed by APL, except for one or two minor 
differences caused by Shoe Cove unique interface requirements. 
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Data were digitized up to 5-bit samples at a peak sampling rate of 45 MHz. 
These data were buffered and :tored on magnetic tape at an average rate of 
117 Mb/s. The tape recorder used was c Martin Marietta 42-track HDDR, identical 
in design to that of the NASA STDN units. SCSS used the recorder in a 39-track 
recording configuration, recorded with the vernier speed control set to 
100 percent. Therefore, all tapes recorded at SNF were fully compatible with 
the WAS A formats. 

The API, equipment was included at the SAR signal simulator for system test 
purposes. The availability of this equipment permitted playback of the digital 
tapes for use in making photographic film recordings of the SAR signal. The 
simulator was equipped with a video regenerator designed to convert digitized 
SAR data back to the previous analog form. The regenerator also provided for the 
extraction and display of various data items, which were multiplexed in the 
recorded digital data system. Also, the regenerator provided control signals to 
the optical signal recorder for PRF rate and coherent trigger synchronization. 


Optical Film Recorder . A twin-transport optical film recorder was pro- 
vided as an intermediate step in the generation of optically processed SAR 
images. The recorder was part of a system under development by DREO and the 
Communications Research Center. The recorder development work was jointly under- 
taken by these agencies as part of the Seasat program. 

The recorder was manufactured by C1R, a Toronto company, and consisted of 
two independent film transport and CRT assemblies, with each transport capable of 
recording one-half swath of the SAR radar echo in real time. Therefore, it was 
possible to record the full 100-kra (54 nm) radar swath in real time. The 
recorder accepted the offset video, coherent trigger, and PRF rate signals, 
together with the time code, from the SAR unique system. These signals were 
then used to control the recorder operation. The recorders operated to produce 
two 25-cm (5 in.) wide signal films. Processing of the film latent image took 
place in Ottawa. The film was then optically processed to generate the SAR 
imagery . 


Digital SAR Processing . Part of the Sursat program involved the develop- 
ment of a digital image processor. This project, ccnducted by McDonald Dettwiler 
& Associates in Vancouver, Involved production of a software digital image proces- 
sor capable of transforming a digitized signal record into an image. 

To implement the ground station acquisition part of ; e system, the existing 
Landsat computer system was modified to provide two 6250-b/in. computer compatible 
tape (CCT) drives, each capable of operating at 125 in./s or 6.25 Mb/s. To pro- 
duce a CCT of the digitized SAR data, the HDRR was operated at l/32nd real tine, 
or 3.66 Mb/s. The serial data stream was format-synchronized, buffered in a 
large (196-kbyte) buffered memory, then output from the memory to the CCT. Tapes 
produced by this system were processed in Ottawa. 
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Low-Rate Telemetry Syste m (LRTS) . The low data rate data siream was 
acquired hv the USB receiver. The received baseband signal was passed to a 
1.6-MHz subcarrier demodulator, where the original split-phase modulation was 
reconstructed. This signal was then synchronized! and interfaced to the Landsat 
computer system for recording ,nd processing. The bit /frame synchronizer and 
the processor interface were instructed as a single unit for installation in the 
computer mo in frame, which proved to be a satisfactory arrangement. The computer 
system implemented the monitoring of the required SAR engineering parameters. 
Monitored parameters were displayed on an interactive CRT, and were hard-copy 
logged to a line printer. The status of each monitored parameter was displayed 
on a special-purpose indicator panel. All data received on the LRT data link 
were recorded on a CCT. This enabled Canadian users to obtain real-time lRT 
sensor data that will be used in future experiments. 


e. Test Plan . The test plan outlines the tests used to verify the 
performance of the various system components. The general test plan followed was 
to use the pre-shipment factory acceptance tests as the basis for integration 
testing. Following installation of an item, the acceptance test procedure was 
repeated as necessary to ensure that integration itself had not caused a problem 


HDRR Acceptance Tests . The HDRR was tested by Martin Marietta, according 
to their test plan, on 16 May 1978. These tests were not witnessed by a Canadian 
government representative because of time constraints. However, the unit was 
delivered to API. for integration with the SAR-unique formatter /simulator. Because 
of the warranty conditions appltcab’e to the equipment, it was not necessary to 
witness t h e a c c e p t a n c e tests. 


System Integration of HDKR/SAR Unique Rack. The SAR unique rack, comprising 
the SAR coherent demodulator, SAR data formatter, and SAR signal simulator, was 
manufactured, assembled, and tested at APL. The APL engineering team was con- 
tracted to accept responsibility f t r integration of a Tau Iron bit error rate 
tester and a Hewlett-Packard oscilloscope. The latter units were supplied by 
CCRS directly to API,. 

The SAR coherent demodulator used for this phase of system integration was 
a brassboard prototype. This unit was used co provide SNF with the capability to 
receive and process the SAR data ahead of scheduled delivery of a production unit. 

Acceptance tests for the complete SAR-unique /HDRR subsystem were conducted 
at the APL facilities during August 1978, The equipment was then shipped to SNF 
where it wn?. installed and again tested by an APL engineering team. 

The subsystem was then integrated to the SCSRS antenna/RF system for final 
checkout. On completion of this work in early September 1978, SNF began record- 
ing digitized SAR data on a regular basis. 
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LRTS Integration . The LRTS was delivered in late July 1978. It was 
installed and tested in the SCSRS system computer using recorded low rate telem- 
etry data. Testing consisted of recording the CCT data from thr, LRT data tape, 
followed by image dumping of statistically selected parts of the CCT. Tape 
dumps were then examined for format validity and data content validity. 

The system was tested for varying input signal-to-noise ratios to ensure 
that all performance specifications were met. As SCSRS was not equipped with 
any form of signal simulator for the LRT data link, testing was confined to the 
use of actual satellite telemetry. 


Analog Recorder . The analog recorder was delivered, installed, and tested 
by a team of engineers from DREO. Testing consisted of demonstrating that the 
record. r spectrum conditioning circuits were functioning properly. As it was not 
possible to play back recorded data at that time, no other testing could be 
undertaken. 


Optical Recorder . A brassboard prototype of an optical signal recorder was 
constructed by DREO personnel and delivered and installed by their staff in late 
July. Testing of this device relied on the availability of actual SAR data, as 
there was no method to simulate or replay recorded data. Testing consisted of 
recording a test film from the SAR data link, then shipping the film to Ottawa 
for development and processing. This proved to be a cumbersome method of handling 
signal film, but was the only available procedure to resolve the problem because 
the primary effort in recorder and processor development was centered in Ottawa. 


c * Schedule . Although there was no specific commitment as to when the 
Shoe Cove station would begin support of the Seasat mission, a goal was estab- 
lished to have the station fully implemented and tested by launch time. Actual 
tracking operations began approximately 45 days after launch. 


13. Oakhanger, England (UKO) Stf.tion Support 

a. Requirements . Requirements of the Oakhanger station were to: 

(1) Track Seasat on all visible passes above 5 deg subsequent to launch 
with minimum dttta loss. 

(2) Collect and record all telemetry information on the 2287.5 MHz car- 
rier and give real-time outputs of eight SAR-related telemetry units. 

(3) Receive SAR data on 2265.1 MHz when scheduled and record the digi- 
tized data on magnetic tape. 

(4) Provide a real-time feedback to GSFC on SAR telemetry units over a 
voice link during supports. 
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b. Implementation . The following items were implemented to meet Seasat 
support equirements: 

(1) The servo system was upgraded to give 10-deg/s maximum azimuth 
velocity. 

(2) A program track was developed for element processing, tracking, and 
acquisition. 

(3) Telemetry equipment was installed (EMR 728 PSK demodulator, 

EMR 2721 signal converter, EMR 2731 frame synchronizer). A Prime 
300 computer was installed for telemetry formatting and recording 
with a real-time readout. 

(4) A telemetry program was developed for the Prime 300 computer to for- 
mat and control tho EMR units. 

(5) A down-converter was installed for SAR reception with a 465.1-MHz IF 
output and 50-MHz bandwidth. 

(6) An MFR was installed. 

(7) A cleanroom was built to house the HDDR. 

(8) An analog recorder (Ampex FR1800) was installed for direct telemetry 
recordings and to facilitate non-real- time CCT production. 


c. Tests . The following tests were completed during preparation for 
mission support: 

(1) Azimuth and elevation servo tests were performed using Landsat after 
initial performance checks proved successful. 

(2) Program track tests and element processing using Landsat signals 
and data. 

(3) SAR system receive tests using Lotal loop check capability of SAR 
ground equipment. 

(4) Telemetry tests using simulated data from an EMR data simulator unit. 

(5) Telemetry program tests using simulated data. 

(6) Crew r training using total system and Landsat. 


d. Schedule . Although there was no specific commitment as to when UKO 

would begin support of Seasat, a goal was established to have the station fully 
implemented and tested by launch time. Actual tracking operations began approxi- 
mately 30 days after launch. 
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i.4. Fleet Numerical Oceanographic Center 


a. Background Information . Fleet Numerical Oceanographic Center (FNOC) 
at Monterey, California, has been developing a sat°llite data processing capa- 
bility to provide a remote sensing data base for use in the Navy's weather fore- 
casting operation. In line with this interest, FNOC planned to use Seasat data 
in the Satellite Data Pr"'*.essor. Concurrently, NASA planned to demonstrate the 
near- real- time use of Seasat data by commercial as well as scientific users. 

As a result of these two interests, an agreement was negotiated between 
NASA and DoD, where FNOC agreed to conduct a real-time user data demonstration 
in support of the Seasat Project. The demonstration was to show that Seasat data 
and related FNOC products could be provided to DoD and industrial and scientific 
users in a timely manner. In addition, FNOC was co be a source for "surface 
truth" products for the verification of Seasat-generated data products. 

The Memorandum of Agreement (MOA) for a real-time user demonstration for 
the Seasat Project* contained a description of the responsibilities of the Seasat 
Project and FNOC with respect to the planned demonstration. Included in the 
described responsibilities was the requir ment for JPL to provide algorithms, 
flow charts, software consulting services, and test data as required by FNOC to 
permit their integration of the geophysical software with the real-time data 
processing facility provided by FNOC. 

This transfer of technological information and data between the Seasat 
Project and FNOC evolved into four interfaces areas: 

(1) The real-time operational data interface. 

(2) The Instrument Data Processing System (IDPS) interface. 

(3) The geophysical algorithm development interface. 

(4) The Auxiliary Data Record (ADR) interface. 

The real-time operational data interface was handled as part of the GDS 
engineering functions under the cognizance of the Seasat Operations Manager and 
is not addressed here. The other three interfaces were handled as part of the 
system engineering function under the cognizance of the Seasat Information 
Processing Manager and are discussed in the following paragraphs. 


b. Technical Approach . Although the transfer requirements, respon- 
sibilities, and content varied for each of the interface areas, a common techni- 
cal approach was used. The basic transfer unit for the transmission of informa- 
tion and data between the Seasat Project and FNOC was defined as a "data package," 
which consisted of telemetered spacecraft data, written material, computer cards, 
and any other matter thai was passed between the two agencies. Each data package 
was forwarded by the transmitting agency to the receiving agency through a letter 


* Project Plan for Seasat-A 1978 Mission , JPL internal document 622-3, Appendix B, 
May 1978 
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of transmittal. To provide for an efficient mechanization of the process, single 
technical points of contact were established within each agency. Each identical 
point of contact was responsible for ensuring that the data packages were prepared 
for transmittal and were transferred (or received). 


c. 1DPS Interface . The IDPS was a part of the Seasat Project Data 
Processing System (PDPS) located at JPL. While FNOC had no direct interface with 
the IDPS in its planned implementation for the Seasat mission, the information 
and knowledge acquired by JPL personnel as a result of the development of the 
IDPS was of interest. As such, the IDPS interface related to the transfer of 
documents, computer program naterial , and ancillary information that was of bene- 
fit to FNOC in the implementation of an IDPS-type capability for the Real-Time 
User Data Demonstration System (RTUDDS) at FNOC. 

Support for the RTUDDS in the IDPS interface area was of an indirect nature 
only. As such, Seasat support was limited to the effort required to prepare data 
packages for transmittal. No documentation or computer software was developed 
in the IDPS interface area whose requirements were based on the needs of the 
RTUDDS. As information of interest to FNOC became available as a result of normal 
IDPS development activities, a data package was constructed for transmission to 
FNOC. 


Information transmitted for the IDPS interface consisted of the following 
elements: 


Data Elements 

Form 

Completeness 

Related documentation 

Documents, lOMs 

As available 

Annotated program listings 

Assembly /Fortran 

As available 

Test /verification iata 

Magnetic tape hardcopy 

As available 


"Completeness," as used above, defines the extent to which a given element was 
comprehensive. For example, related documentation might not be available for 
each program element or routine. The precise format of the information trans- 
ferred as a data package was specified in the letter of transmittal. The primary 
information transferred consisted of the IDPS location processor routines, per- 
tinent data tapes (A/0 and PMDF) , and channel tabulation hardcopy. 


d. Geophysical Algorithm Development Interface . JPL was assigned the 
responsibility for coordinating the development of the algorithms and prog'ams 
required for geophysical conversion. These algorithms and programs were primarily 
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supplied by the sensor implementation managers and the experiment teams. The 
algorithms and programs were developed on the Algorithm Development Facility 
(ADF), an element of the POPS at JPL. 

As these algorithms and programs were developed, various data elements were 
transmitted to FNOC. These data elements contained information that ranged from 
the specification sheets for each a'gorithm to th° actual debugged and validated 
software. Data elements were provic d for each of the scientific instruments on 
board the spacecraft with the except on of the SAR. FNOC used the algorithms 
and programs for producing the geoph^ical software before use in the RTUDDS. 

Information transmitted Cor th : geophysical algorithm development interface 
consisted of the following elements; 


Data Elements 

Form 

Completeness 

Related documentation 

Documents, IOMs, diagrams, 
specification sheets 

As available 


Software products 

Annotated program listings* 
magnetic tape cards 

As requested 
available 

and 

Test data 

Test reports* test decks 

As requested 
aval lable 

and 


As planned by FNOC, the RTUDDS implementation would only process altimeter 
data to the "sensor file" level and would not process visual and infrared 
radiometer (VIRR) data. FNOC planned to process both Scanning Multichannel 
Microwave Radiometer (SMMR) and Seasat Scatterometer System (SASS) data to the 
"geophysical file" level. 


e. Auxiliary Data Records Interface . As an operational weather center, 
FNOC produced a number of standard data products that were a source for surface 
truth data. This group of data products were designated as Auxiliary Data 
Records (ADRs) by the Seasat Project. 
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The interface functions consisted of making arrangements for having FNOC 
make the data products available to the Seasat Project. The information trans- 
mitted by FNOC for the ADRs interface consisted of the following elements: 


Data Elements 

Form 

Completeness 

FNOC field data 

Magnetic tape 

As requested 

FNOC spot data 

Magnetic tape 

As requested 

Operational plots 

Hardcopy 

As available 

Spectral Ocean Wave Model (SOWM) products 

Hardcopy 

As requested 


f. Future FNOC-Type Interfaces . It is appropriate to analyze the FNOC 
interface as a historical learning process. Most of the problems encountered 
were somewhat predictable and were more management-related than technically 
related. 

Although the Seasat Project and FNOC had a signed MOA with respect to the 
RTUDDS , there was some confusion in the interpretation of the document. Not 
surprisingly, each tended to interpret the MOA in the manner most favorable to 
the particular point they were attempting to accomplish. 

From the interface function perspective, the most significant problem was 
a disparity between the Seasat Project and ^NOC with respect to the schedule for 
algorithm development. As viewed by the project, FNOC was processing satellit.. 
data in support of a project experiment. Theiefore, the time frame for accom- 
plishing the experiment was related to the project algorithm development plans. 
However, FNOC had made non-Seasat Pro^ i-relat ed commitments to provide the 
satellite data to other DoD agencies. As viewed by FNOC, they had a requirement 
to have available at launch a capability to support their other commitments. If 
this difference in needs had been identified at the time the MOA was generated, 
perhaps it could have been better resolved than after the fact. As it was, 
concurrent geophysical algorithm implementation at JPL and at FNOC was attempted. 

The second significant item was the projected requirement to verify FNOC's 
software implementation. As viewed by the Seasat Project, when FNOC distributed 
data to industrial users that was identified as Seasat data, then the project 
wanted to verify the data prior to distribution. To accomplish this, it was felt 
that it would be necessary to certify FNOC's implementation. It should be noted 
that concurrent algorithm implementation tended to increase the difficulty of 
resolving this item. As the satellite aborted the mission before the completion 
of algorithm implementation, the item was resolved by default. 
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From a technical viewpoint, the interface function seemed to work well. It 
was aided by having a single point of contact, especially at JPL. Although a tech- 
nological transfer of geophysical algorithms is possible, concurrent development 
activities increases the difficulty. In general, the transfer of ADRs from FNOC 
to JPL presented few problems except from a schedule coordination point of view. 


15. Project Data Processing Subsystem (PDPS) 

The PDPS comprised the IDPS, Master Sensor Data Record (MSDR) , and the 
ADF used by the experiment teams to develop algorithms for converting telemetry 
data to geophysical units (e.g., wind fields, temperatures, altitudes, wave 
heights, etc.). The PDPS was created primarily to receive the Project Data 
Package (PDF) from GSFC on a daily basis after launch. It was also responsible 
for the GSFC /JPL /NASCOM link used by the Mission Planning Subsystem (MPS) to 
transmit sequence profiles to GSFC and the resulting command lists back to JPL. 
This function was independent of the IDPS, but was implemented and operated by 
essentially the same personnel. 


a. Requirements 

IDPS . Requirements of the IDPS were to receive the daily PDP from GSFC and 
to perform a somewhat standardized set of data processing activities. The daily 
PDP consisted of eight Project Master Data File (PMDF) magnetic tapes, each con- 
taining a 3-h block of telemetry data and one attitude/orbit (A/0) magnetic tape 
containing a 24-h orbit file. The primary output product was the MSDR, which was 
a magnetic tape consisting of data records for each satellite sensor and for the 
engineering data. The output record for any sensor consisted of telemetry data 
that were decommutated, time-tagged, converted to engineering units, and Earth- 
located. The Earth location processor used the A/0 tape to calculate the latitude 
and longitude of the boresight intercept of each sensor's antenna with the 
Earth's surface at a set of times unique to each sensor, 

Other magnetic tape data products included the Sensor Data Records (SDRs) 
for individual sensors or for the engineering data. Paper products included 
performance summaries, channel tabulations, and channel plots. These products 
were intended for use early in the mission during the engineering assessment of 
individual sensor and spacecraft bus performance. The functional requirements 
for the IDPS are outlined in the IDPS Functional Specif icatio.., JPL internal 
document 622-14. 


MPS /NASCOM Link . The requirements for the GSFC/JPL full-duplex NASCOM link 
used by the MPS were specified by the Seasat Ground Data System Engineer (GDSE) . 
Three types of records generated at JPL by the Mission Planning Team (MPT) were 
transmitted to GSFC: 

(1) A command dictionary that defined the name and bit pattern of each 
spacecraft command. 

(2) Definitions cf groups of commands in a given sequence that could be 
identified by a group name. 
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(3) Mission sequence, which used individual commands and group commands, 
but which lacked the specific transmission or execution times 
dependent on the STDN scheduling. 

The record transmitted to JPL by GSFC was the resultant command list, which 
included times dependent on the STDN scheduling. 


b. Implementation 

IDPS . The IDPS was implemented on the Mission Control and Computing Center 
(MCCC) institutional Data Records System (DRS), which used two IBM- 360-75 com- 
puters. The MCCC DRS provided the existing development and operations environ- 
ment used by the Seasat Project. All of the software developed was unique to, 
and funded by, the Seasat Project. The MCCC DRS was operated by the Data Manage- 
ment Team (DMT), a multimission activity. The Seasat Project funded its part of 
the DMT. 


MPS/NASCOM Link . The MPS/NASC.OM link was implemented on the MCCC real-time 
system, which used a single IBM 360-75 computer (not one of the two DRS machines). 
This link used an existing design currently supporting another project. Link 
operations were provided by the MCCC institutional operations and scheduling 
staff. 


c . Testing 

IDPS . Some data flow tests to provide a PDP for processing were the only 
planned formal tests involving the IDPS. These tests were made, although several 
individual PMDF and A/0 tapes were received and used for format and structure 
tests. The IDPS did use satellite data tapes recorded during pre-launch testing 
at LMSC. The LMSC tapes and a JPL-developed simulation capability provided the 
only testing of the IDPS before launch. 

Because of this inadequate testing, it was anticipated that many problems 
would be encountered in the IDPS software when actual data became available after 
launch. This, in fact, was the case. At the time of the anomaly, the IDPS was 
on its sixth software revision, and five more revisions were delivered to opera- 
tions after that time. Most of these 11 revisions were only minor corrections; 
ac least two, however, were major revisions that included both significant addi- 
tional capability as well as corrections. 


MPS/NASCOM Link . The MPS/NASCOM link was tested extensively by the MCCC 
institutional personnel in conjunction with GSFC personnel. The data transmitted 
to GSFC were generated by the MPT at JPL using the same programs developed for 
flight operations. The command list was generated at CSFC using flight operations 
software. This command list was then transmitted to JPL to test the other half 
of the full-duplex link. 
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d. Schedule . 

IDPS . The scheduled date of 15 February 1978 for a CDS test of the PDP 
Interface between GSFC and the IDPS and the scheduled date for launch readiness 
were the only significant milestones. Both of these dates were met. 


MPS/NASCOM Link . The scheduled date of 15 November 1977 for a GDS test of 
the link and the scheduled date for launch readiness were the only two significant 
milestones. The readiness date for the GDS was slipped by about 4 months. The 
link was ready for support to the satellite launch activities. 


e. Data Turnaround Time . The planned pre- launch time estimate of sensor 
data record availability to the sensor evaluation task groups for geophysical 
algorithm development and to the sensor managers for engineering performance 
evaluation was 12 days after data acquisition by the STDN site. This 12 days 
was allocated as follows: 


(1) 

STDN handling: 

1 day. 

(2) 

IPD processing: 

6 days. 

(3) 

Shipment to JPL: 

1 day. 

(4) 

IDPS processing: 

4 days. 


The day for STDN handling was intended to permit all on-site data processing, 
formatting, and transmission over NASCOM lines to GSFC. Also to be included in 
this day was the time for retransmission to GSFC of data not considered acceptable 
by the quality criteria, but recoverable at the receiving site from either the 
analog magnetic cape prior to telemetry frame synchronization or from the digital 
magnetic tape used to drive the NASCOM lines. Once received at GSFC by TELOPS, the 
I PD data system used to terminate the NASCOM telemetry transmissions, the data 
were organized into pre-edit files corresponding to the original satellite-to- 
STDN site transmission. At this point the data, in the form of pre-edit files, 
was made available to the Telemetry Processing System (TPS) in IPD for its 
6 days of data handling. 

The IPD/TPS processing task consisted of organizing the pre-edit files into 
chronological order and extracting data on a 24-h GMT day basis. The engineering 
data from the 24-h GMT day file was sent to the ADF, where the satellite attitude 
error history was created and provided to IPD. Also provided to IPD were the 
GMT daily orbit file from the Orbit Determination Facility and the actual satel- 
lite UTC clock offset from the POCC. When all of these data were available, the 
24-h GMT daily telemetry file was written on magnetic tape as the PMDF. The 
attitude history file, UTC clock offset, and the orbit file were written on the 
A/0 magnetic tape. These tapes were individually checked and prepared for 
shipment to JPL. 
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One day was allotted for shipment. The plan called for morning deliveries 
of data to the Baltimore airport by the GSFC transportation department. The 
information concerning flight number and waybill number were to be telephoned 
to JPL for vendor pickup to be arranged. The data would then be delivered in 
the evening of the day shipped. The data packages were received by the Mission 
Control Center Operations (MCCO) data library expediting service. 

The 4 days at JPL included 1 day for the MCCO library personnel to unpack 
the data packages, inventory the contents, acknowledge receipt, enter the data 
tapes in the MCCO library, and inform the DMT of the availability of the data. 

The DMT used the remaining 3 days for processing, analysis, and record keeping 
functions. The processing consisted of a two-step activity with an analysis 
period after each step. The first step was a simple tape dump similar to the 
GFSC/IPD tape check process. This dump program provided the initial quality 
control screening for tapes with such commonly noted problems as read errors, 
time-tag errors, and data gaps. The second step was the processing of the data 
to the daily MSDR, which constituted the Seasat Project's archival data base for 
additional geophysical processing and data evaluation. The DMT was responsible 
for keeping records of all tapes processed. 

This 12-day processing cycle to data availability in MSDR form was not met. 
The 1 day for STDN handling to prepare a GMT day's data for IPD was typically 
over a week and frequently several weeks. There were several problems, the pri- 
mary one being the inability of the STDN and NASCOM lines to handle, on a con- 
sistent basis, the large volume of data received from the satellite. The 
unexpectedly large number of retransmissions of data from the STDN sites to GSFC 
competed with the primary transmissions and caused severe loading and scheduling 
problems. One other, not so obvious, problem was caused by the requirement for 
data transmission to IPD on a complete GMT day basis. The data were sent to 
TELOPS on a satellite tape recorder dump basis of 3- to 4-h duration. To provide 
a sufficient data time span to extract one complete GMT day, as many as 8 to 10 
consecutive satellite tape recorder dumps had to be received successfully by 
TELOPS. 

In general, most of the data were received successfully within a day or so, 
but could not be used because of one or more bad transmissions and the difficul- 
ties of obtaining data. A number of workarounds and plans were implemented to 
alleviate this situation. The inability to consistently and successfully obtain 
data from the STDN sites to GSFC was one of the most severe data handling pro- 
blems faced by the Seasat Project. The TELOPS processor was a new system brought 
on-line by IPD shortly before the Seasat launch. The TPS was the existing IPD 
processor containing the Seasat applications software. These two systems both 
required considerable reprogramming effort as actual experience was gained in the 
handling of flight data. The performance of these systems, while marginal to 
poor initially, became satisfactory as problems were isolated and corrected. 

The shipment of data generally required only*! day. The only serious 
problem was the inconsistency by the GSFC transportation department in notifying 
the MCCO library expediting service or the JPL transportation department of a 
shipment in progress. This usually caused a delay of at least 1 extra day to 
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coordinate the pickup of the data for delivery to JPL. The longest delay was 
2 weeks for a single tape when JPL was not informed of the shipment by GSFC. 

The processing to the MSDR by the DMT at JPL using the 1DPS was never held 
to the 4-day schedule. The data deliveries to JPL in the early days of the 
mission were very sporadic, non-chronological , and uncertain. The received data 
were processed immediately by both the DMT and by the development programmers in 
the 1DPS. The data deliveries from GSFC were so slow overall that the IDPS 
software problems were isolated and corrected without impacting data delivery 
for additional geophysical processing. Some of the data received early in the 
mission were reprocessed several times with continuously upgraded software. The 
IDPS program basically reached their form about the time of the satellite failure. 
The complete history of the MSDR deliveries to IDPS during the lission is plotted 
on Figure 2-21. 

Shortly after the failure, all of the PMDF tapes at JPL were returned to 
GSFC for removal of a time regression introduced as an artifact by the IPD 
processing. Also, a problem in the attitude history file generation was detected 
that required the reprocessing of a number of A/0 tapes. 

A/0 tapes were corrected by March 1979. The set of PMDF and A/0 tapes was 
finally complete at JPL and processed to the MSDR level by the DMT by the end of 
April 1979. 


D. POS TEST AND TRAINING 

The objective of the POS test and training plan was to systematically 
develop and demonstrate the readiness of the POS (hardware, software, personnel, 
and procedures) to support Seasat launch and mission operations. To achieve 
this objective, a phased program was used that included classroom training, simu' 
lation exercises, satellite system test support, and operational demonstrations. 
Each of these activities is discussed in the following paragraphs. A POS test 
chronology is given in Table 2-10. 


1. Classroom Training 

Between October 1977 and May 1978, five lecture sessions were presented to 
Seasat teams at GSFC. These sessions lasted from 1 to 10 days each and covered 
detailed descriptic s of the mission profile, operations organization, ground 
data system, satellite vehicle, and science payload. JPL Mission Planning and 
Mission Control Teams, LMSC, Univac, and science sensor representatives presented 
180 h of instruction. Training manuals were assembled from classroom materials 
and were retained for reference in the control center. 

2. Simulation Exercises 

Simulation ..ercises were conducted in three phases: (1) intra-team; 

(2) inter-team; and (3) combined POS. Each phase was designed to accommodate 
the development schedule for team procedures and GDS capabilities. A chronology 
of team exercises and GDS readiness dates is given in the following paragraphs. 
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Figure 2-21. PMDF Delivery Schedule 





Table 2-10. POS Test Chronology 


Hate 


Event 


12/15 

U/16 

1978 

1/6 

1/27 

2/1 

2/15 

2/17 

2/22-24 

2/27 

2/28 

3/16 


3/20 

3/23 

3/24 

3/27 

3/31 


POCC Version 4 (test version). Operational 
Intra-Team: Telemetry Command 

Intra-Team: Tape Recorder Operation 

Intra-Team: SAR Operation 

Orbit Determination System, Operational 

POCC Version 5, Operational 

Intra-Team: Launch and Early Orbit 

Intra-Team: Orbit Adjust (three parts) 

POCC Version 6, Operational 

Intra-Team: Sensor Activation 

Inter-Team: Launch and Early Orbit 

Attitude Determination System, Operational 
Command Management System, Operational 
Information Processing Division, Operational 

POCC Version 7, Operational 
Network (Program II), Operational 

Inter-Team: Launch and Early Orbit (retest) 

Inter-Team: Orbit Adjust 

MCCC (JPL) , Operational 

Inter-Team: Se* -sor Activation 


c -2_ 

Ul \ ^ * 
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Table 2-10. POS Test Chronology (Continuation l) 


Date 


Event 


4/3 POCC Version 8, Operational 

4/6 Inter-Team: Launch and Early Orbit (retest) 

4/12 Combined POS: Launch and Early Orbit 

4/15 Flight Maneuver Analysis, Operational 

4/20 Inter-Team: Attitude Trim (two parts) 

4/24 POCC Version 9, Operational 

5/9 Combined POS: SAR Targets of Opportunity 

5/15 POCC Version 10 (launch version). Operational 

5/16 Combined POS: Launch and Early Orbit 

5/18 Combined POS: Orbit Adjust (four parts) 


a. Intra-Team Exercises . These exercises emphasized real-time opera- 
tions procedures and POCC capabilities. Between 16 December 1977 and 28 Feb- 
ruary 1978, nine exercises totaling 28 h were supported by MCT, SPAT, and POST. 
Of the eight test categories performed, only one was determined to be unsuccess- 
ful by the test supervisor. The test failure was attributed to spacecraft 
simulator problems. These problems were corrected, and a retest on 28 February 
was successful. 


b. Inter-Team Exercises . These exercises expanded simulation partici- 
pation to include non-real-time planning and analysis functions. Although the 
test categories and control center procedures used for intra-team testing 
remained essentially unchanged, data and procedural interfaces were exercised 
with the Mission Planning, Command Management, Orbit Determination, Attitude 
Determination, and Maneuver Analysis Teams. Seven tests, totaling 32 h, were 
conducted between 16 March and 27 April 1978. The launch and early orbit exer- 
cise was conducted three times, primarily because of data flow problems with the 
Simulation Operations Control Center (SOCC). The other three test categories 
were considered functionally successful, although all test reports indicated 
problems with the processing and distribution of satellite playback data. 
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C. Combined POS Exercises . For these exercises, the operations teams 
and end-to-end ground system were joined in a series of mission event simulations. 
Network support was provided by the MAD, MIL. Greenbelt, and ULA tracking sta- 
tions. Four exercises totaling 30 h of real-time operations were conducted, 
including a launch and early orbit simulation supported by the Western Test 
Range (WTR) launch operations complex. All tests were considered successful. 

As in inter-team testing, however, satellite playback data processing was identi- 
fied as a problem area. 


3. Satellite System Test Support 

As part of the POS training program, the MCT and SPAT conducted satellite 
system test activities. In February 1978, the LMSC Lead Monitor Analysts par- 
ticipated in the baseline simulated flight test at LMSC. The POCC was also 
configured for listen-only support of the thermal /vacuum and flight readiness 
(countdown) tests during April and May. During these three tests, more than 
50 h of spacecraft data were analyzed and stored on history tapes for subsequent 
processing and display validation. 

In March 1978, a satellite compatibility test was conducted using the STDN 
Compatibility Test Van (CTV) located at the LMSC Seasat facility in Sunnyvale. 
The test was conducted in two parts on 11 and 13 March. Part I consisted of a 
sate 1 1 ite /POCC (end-to-end) test. The test successfully demonstrated the com- 
patibility of tracking, telemetry, and command interfaces between the satellite 
and the POS. Compatibility test results are documented in Part II of the Ground 
Data System Test Report. 


4. Operational Demonstrations 

As previously stated, the primary objective of the test and training plan 
was to demonstrate operational proficiency before the Seasat launch. Accordingly, 
three operational demonstrations were performed in May and June 1978. A mission 
planning and mission control exercise conducted during the week of 8 May demon- 
strated the capability to transfer and validate command data consistent with the 
mission profile. Reaction procedures for satellite and GDS anomalies were dem- 
onstrated in four exercises during the week of 15 May. The Mission Dress 
Rehearsal /Operational Readiness Test (MDR/ORT) , conducted during the last 7 days 
before launch, was the final demonstration. The MDR/ORT was conducted in the 
final mission configuration and verified the readiness of the POS to perform the 
functional sequences that comprised the Seasat mission. 


E. CONFIGURATION CONTROL 

Beginning in February 1978, the hardware, software, and operational pro- 
cedures comprising the leasat POS were systematically placed under configuration 
control. Changes to the requirements or design of interactive POS elements were 
subject to approval by a Change Control Board consisting of the Project Opera- 
tions Manager, JPL MCCC Manager, GSFC Mission Operations System Manager, and the 
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Chief of Mission Operations. The purpose of this board was to ensure that the 
integrated POS was maintained at an operational level adequate to support per- 
sonnel training, launch, and flight operations. 

Three levels of control criteria were employed: 

(L) Configuration control. 

(2) Modified ccnf iguration control. 

(3) Configuration freeze. 

Criteria definitions and their applicability to Seasat POS development and 
flight operations activities are shown in Tables 2-11 and 2-12. 


Table 2-11. Configuration Control Definitions 


Control Level 

Definition 

Configuration control 

Changes limited to those that allowed 
accomplishment of mission requirements, 
as scheduled 

Modified configuration 
control 

Same as above, but required operations 
concurrence and system demonstration 
after modification 

Configuration freeze 

No system modifications; configuration 
broken only to restore from system 
failure. System demonstration required 
after restoration 


2-84 


Table 2-12. Configuration Control Schedule 


Configuration 

Freeze 



MPS 

CMS 

ADS 

ODS 

FMOC 

I PI) 

PDPS 


Integration 
delivery to 
L - 30 days 

L + 17 days 
end of mis;- 1 
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LAUNCH AND ORBIT INSERTION PHASES 


A. INTRODUCTION 

This section discusses the launch and orbit insertion phases of the Seasat 
mission. The launch phase is defined as that time period from liftoff to Agena 
second burn cutoff , and the orbit insertion phase as that from second burn cutoff 
to momentum wheel attitude control capture (12 to 25 h) . 


B. GROUND SYSTEM LAUNCH CONFIGURATION 

1. Western Test Range 

The WTR ground data system configuration is shown in Figure 2-19. All pre- 
launch direct control of the Atlas launch booster, Agena, and Seasat satellite was 
accomplished from the launch operations building (LOB) at Space Launch Complex-3 
West (SLC-3W) . During the initial boost phase after launch, both the WTR tele- 
metry receiving station and NASA telemetry (TLM) antenna tracked the launch 
vehicle until loss of signal occurred. Two Advanced Range Instrumentation Air- 
craft (ARIA) were used to receive and transmit telemetry data during the first 
and second burns of the Agena propulsion system. 

Radiometric data tracking of the launch vehicle was accomplished using the 
WTR radar tracking network. 


2. Spacecraft Tracking and Data Network 

The detailed STDN configurations are defined in GSFC document STDN-601/ 
Seasat, Network Operations Support Plan (NOSP) . 

Six stations (MAD, ULA, GDS, HAW, ORR, and ACN) were used for launch sup- 
port. MAD, ULA, and HAW were under configuration freeze (configuration broken 
only to correct failures; demonstration after restoration) nnd unavailability of 
their support was declared as launch hold criteria. GDS, ORR, and ACN were under 
configuration control (meet scheduled support). 

The pre-pass checkout of these stations began four hours before liftoff and 
was completed in the order of ACN, ORR, HAW, GDS, ULA, an A MAD. There were no 
launch vehicle requirements from the STDN stations; however, all stations pro- 
vided normal spacecraft tracking support. 


3. Project Operations Control Center 

The POCC for Seasat was a part of the Multi-Satellite Control Center II 
(MSOCC II) complex. MSOCC II supported two other satellites besides Seasat and 
contained three identical Sigma 5 computers. 
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From launch minus 4 h to launch plus 8 h, one of the other two Sigma 
computers provided a hot backup to the Sigma 5 computer U3ed for Seasat opera- 
tions. This backup computer was loaded with the Seasat operating system and data 
base. In case of problems, the computer switching could have been made In approx- 
imately 1 min. 

The software required to support the Sigma 5 computer system consisted of 
a Xerox real-time batch monitor (RBM) operating system and Seasat applications 
programs designated SEAC. The SEAC software provided the control center personnel 
the capabilities to monitor and command the activities of the spacecraft sub- 
systems and sensors. The SEAC software was grouped into the following categories! 

(1) Control Subsystem, which provided the functions required to service 
other programs. 

(2) Telemetry Subsystem, which provided the capability to receive two 
inputs of data concurrently. One input could be recorded, processed, 
and displayed; the other input could be recorded and processed later. 

(3) Command Subsystem, which provided for command generation from key- 
boards and a general-purpose console, transmission of commands to the 
tracking station, verification of the results of the commands, and 
the creation of the Command Master Data Record (CMDR) . 

(4) Display Subsystem, which provided capabilities for the display of 
commands and telemetry on CRT displays, line printers, and strip 
chart recorders. 

Version 10.003 of the SEAC software was used to support the spacecraft 
launch. This system tape was produced on 12 June 1978, and was under configura- 
tion control. Liens against this software are summarized as follows: 



Type 

Written 

Open 


Discrepancy reports 

107 

15 


Enhancement reports 

31 

11 


The most significant discrepancy was the requirement for patches for Scan- 
ning Multichannel Microwave Radiometer (SMMR) special processing (square root 
routine for calculating standard deviation-produced negative numbers). This 
problem was solved by creating another system tape with these patches. This tape 
was used, as required, for SMMR special processing. This decision had no impact 
on launch support. These patches were later incorporated in system tape 10.004, 
created on 3 July 1978. 


4. 


Orbit Determination Operation > 


The Orbit Computational Engineer from the Operations Support Computing 
Division was responsible for pre-launch and post-launch orbital computations, 
orbit determination, tracking data dissemination, and all other related support 
activities. 

During launch, high-speed data in the form of position and velocity vectors 
in an Earth-fixed coordinate frame were received at GSFC by the Goddard Real-Time 
System (GRTS) from the launch support function at WTR. These high-speed data 
were used to drive the displays in the operations control viewing area. These 
data were available to GRTS at GSFC until the time of WTR loss of signal (LOS) 
during the first burn of the Agena stage. 

The GRTS was used to perform orbital computations based on S-band tracking 
data from the STDN sites. The S-band tracking data were transmitted by teletype 
data links from the participating STDN stations by the GSFC NASCOM message switch- 
ing system and then directly to the IBM 360-75 computer complex in near-real time. 
The orbital parameters and other pertinent data from these computations were made 
available to designated recipients in the operations areas. 


C. SEQUENCE OF EVENTS (PLANNED VERSUS ACTUAL) 

The Seasat satellite was launched from AFWTR by an Atlas/Agena launch 
vehicle at 01:12:44 GMT on 27 June 1978. The plotboards driven at GSFC Indicated 
near-nominal vehicle performance. The vehicle was tracked by the AFWTR tracking 
network and by the ARIA 1 aircraft through the Agena first burn shutdown and by 
the ARIA 2 aircraft during the Agena second burn. Tables 3-1 through 3-4 list the 
planned versus actual events. 


D. LAUNCH SITE ACTIVITIES 

The AFWTR launch activities sequence in support of Seasat data requirements 
are listed in Table 3-5 and shown in Figure 3-1. All elements of the launch 
ground data system functioned properly except the ARIA Indian Ocean/Marisat/ 
AFETR/LES-9 real-time telemetry satellite data link. As had been experienced in 
all GDS testing, excessive bit errors (>50 x 10“^) received at the WTR Telemetry 
Receiving Station (TRS) through the link were responsible for only a limited 
amount of data being received. Radio frequency interference (RFI) and modulation 
products were the most likely candidates to explain the experienced problems. 
However, the data link coordination control did not allow expedient fault isola- 
tion of the problems. The Air Force Indian Ocean Station (AFIOS) did record the 
Agena second burn events. With quick turnaround (launch plus 5 min), it success- 
fully retransmitted the telemetry data to VAFB/TRS and to KSC/WLOD Telemetry 
Processing Station (TPS), where the data were processed and analyzed by the LMSC 
data van and JPL and LMSC analysts. All data received at the KSC/WLOD TPS were 
also successfully transmitted to the POCC Sigma 5 computer at GSFC, 
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Table 3-1. Launch Phase Programmed Events 




Time Relative 

to Liftoff,s 


No. 

Event 

Planned 

Actual 

Comments 

1 

Booster engine cutoff 

130 

130 

WTR coverage 

2 

Booster engine jettison 

133 

133 

WTR coverage 

3 

Shroud jettison 

208 

208 

WTR /ARIA 1 coverage 

4 

Sustainer engine cutoff 

285 

285 

WTR/ARIA 1 coverage 

5 

Start CTU clocks 

290 

290 

WTR/ARIA 1 coverage 

6 

VECO enable 

300 

300 

WTR/ARIA 1 coverage 

7 

VECO 

304 

304 

WTR/ARIA 1 coverage 

8 

Separation 

309 

309 

WTR/ARIA 1 coverage 

9 

First burn start 

386 

386 

WTR/ARIA 1 coverage 

10 

First burn shutdown 

617 

617 

ARIA 1 coverage 

11 

Second burn start 

3436 

3442 

ARIA 2 coverage 

12 

Second burn shutdown 

3442 

3442 

ARIA 2 coverage. 

ARIA 2 reported time 
for this event was in 
error. ARIA 2 data 
as processed in POCC 
were unusable 


E. MISSION OPERATIONS ACTIVITIES 

The POCC for the GSFC support of the Seasat mission was the Seasat Opera- 
tions Control Center (Seasat OCC) located in building 14 at GSFC. The POCC was 
the focal point of project-unique operations, planning, and monitoring. 

During the launch, the mission control function was performed in the 
Mission Control Room (MCR) . The following personnel were present in the MCR: 


(1) Project Operations Manager. 

(2) Mission Support Manager. 
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Table 3-2. Orbit Insertion Phase Programmed Events 




Time Relative 

to Liftoff, s 


No. 

Event 

Planned 

Actual 

Comments 

1 

Oxidizer dump start 

34 A 5 

3445 

ARIA 2 coverage 

2 

Orbit antenna 1 deploy 

4551 

4551 

MAD coverage 

3 

Fuel dump start 

5107 

5107 


A 

Solar arrays deploy 

5640 

5640 

ULh/GDS coverage 

5 

Deploy SAR data link 
antenna 

6199 

6199 

HAW coverage 

6 

Deploy SASS antennas 1,3 

6209 

6209 

HAW coverage 

7 

Deploy SASS antennas 2, A 

6234 

6234 

HAW coverage 

8 

SAR antenna 90 deg 
pitchout 

6409 

6409 

HAW coverage 


(3) Ground Data Systems Engineer. 

(4) Launch Coordinator. 

The following personnel were not required to be present in the MCR, but 
were in constant communications with the Mission Support Manager: 

(1) Orbit Computations Engineer. 

(2) Attitude Determination Engineer. 

(3) Network Operations Director. 

In the Seasat POCC, the following personnel were present: 

(1) Chief of Mission Operations. 

(2) Two Assistant Chiefs of Mission Operations. 
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Tabic 3-3. Orbit Insertion Phase Non-rro^rammed Events 




STDN and 

Rev Number 


No. 

Event 

Planned 

Actual 

Comment e 

1 

Solar array rotation 

HAW 1 

ACN 1 

S/C receiver not 
locked on HAW uplink 

2 

SAR antenna 90 deg rotate 

ORR 1 

ULA 2 

ORR. Negative 
acquisition 

3 

SAR antenna extended 

MAD 2 

HAW 2 


4 

SAR antenna extend motor 
shutoff 

uLA 2 

HAW 2 


5 

CTU B off 

MAD 2 

ULA 5 


6 

Tranet amplifiers on 

MAD 2 

MIL 4 


7 

Converter 3 on, 1 off 

HAW 2 

GWM 9 

Sequence not correct 

8 

Clock preset 

UL A 3 

AGO 5 


9 

Start PMW 

ULA 3 

ULA 4 


10 

Start RRW 

GWM 4 

GWM 4 


11 

Successful wheel capture 

MAD 16 

ACN 16 

Four attempts were 
made earlier, but were 
unsuccessful 


(3) Two SPAT Teams. 

(4) SPAT Leader. 

(5) SPAT Lead Monitor Analyst. 

Other LMSC experts were required to be in the Launch Support Room, and were in 
communications with the Lead Monitor Analyst. 
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Table 3-4. Activities Planned But Not Carried Out 
(£♦>•- System*. Performance) 


No. 

Event 

Planned Time 

Comments 

1 

Switch transmitters 

ULA 1 


2 

Ranging 

MAD 1 

5 min, 00 s, ranging 



HAW 1 

1 min, 20 s, ranging 



ACN 1 

4 min, 00 s, ranging 



MAD 2 

1 min, 00 s, ranging 



ULA 2 

1 min, 00 s, ranging 



HAW 2 

1 min, 00 s, ranging 



ORR 2 

4 min, 00 s, ranging 



ACN 2 

10 min, 00 s, ranging 



GWM 4 

5 min, 00 s, ranging 


1. Telephone Communications 

Telephone communications were established for the Seasat mission to provide 
for effective control, liasion, coordination, and data collection. It was the 
responsibility of the Assistant Chief of Mission Operations (ACMO) to be aware of 
all activities and the status of the other teams. The ACMO received periodic 
reports from: 

(1) Mission Support Manager. 

(2) Control Center Operations Manager. 

(3) Network Operations Manager. 

(4) SPAT Lead Monitor Analyst. 
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Table 3-5. Launch Activities Supporting Seasat 
Data Requirements 


No. 

Event /I tern 

Time 

1 

High-speed simulated data flow and IRV validation 

L - 100 min 

2 

ARIA (10) /GSFC validation (BERTS and simulation tape) 

L - 90 min 

3 

Agena final readiness (Task 5) 

L - 65 min 

4 

T - 60 min jimsphere balloon release (6) (contingency) 

L - 60 min 

5 

ARIA (PAC)/TRS revalidation (BERTS) 

L - 40 min 

6 

LOX tanking (Task 6) 

L - 35 min 

7 

Satellite vehicle open loop radiation 

L - 30 min 

8 

ARIA (PAC) configuration for mission support 


9 

Terminal count (Task 7), telemetry flight recorder on 

L - 13 min 

10 

Range green 

L - 3 mir. 

11 

Liftoff 

L - 0 min 

12 

Transmit real-time high-speed data to GSFC 


13 

ARIA (PAC) Tacsat carrier on 

L + 60 s 

14 

ARIA (PAC) AOS 

L + 180 s 

15 

ARIA (PAO/R0S report 3 mark events (GMT time with 

L + 616.5 s 


event readouts) 


16 

ARIA (PAC) /ROS report 1 mark event 

L + 636.5 s 

17 

ARIA (PAC) LOS 

L + 720 s 

18 

Transmit IRV to LMSC and GSFC 

L + 800 r 

19 

ARIA (I0)/TRS data flow (BERTS) 

L + 1200 o 

20 

ARIA (I0)/TRS data flow (BERTS) 

L + 2100 s 


ARIA INDIAN OCEAN 



Figure 3-1. Seasat Launch Support Profile 


2 


Displays 


Pre- launch and real-time launch data pertaining to the mission were displayed 
on illuminated screens at the front of the Operations Control Area (OPSCON) . The 
operations center branch was responsible for the implementation and operation of 
these displays: 

(1) Launch count. 

(2) Launch events and orbital elements. 

(3) Flight path angle versus velocity ratio. 

(4) Subsatellite plot. 

(5) Countdown clock. 

(6) Tracking and telemetry schedule. 

(7) Acquisition elevation angles and mark events. 

(8) Picture screen. 


F. SYSTEMS PERFORMANCE 

At launch, the powered flight trajectory of Seasat produced an injection 
orbit that was within specifications, although somewhat off the nominal values 
(Table 3-6). Figure 3-2 shows LMSC Monte Carlo-modeled distributions for the 
orbit parameters of interest. The AV required to correct the launch orbit was 
6.3 m/s compared to a nominal value of 4.4 m/s and a 99 percent probability 
level of 11 m/s. 


G. GROUND SYSTEM PERFORMANCE 

Information available at GSFC indicated that the WTR and the ARIA deployed 
over the Pacific Ocean (overlapping with WTR) acquired Seasat launch telemetry 
(25 kb/s) in accordance with the pre-flight planned timeline. The data were 
transmitted in near-real time to the LMSC computer van at WTR and the POCC at GSFC. 

The second ARIA supporting this phase of the mission, deployed over the 
Indian Ocean, acquired the spacecraft telemetry downlink only intermittently, 
providing no usable telemetry data to either WTR or the POCC. The Air Force 
Satellite Control Facility (AFSCF) Indian Ocean Station, however, provided nearly 
redundant coverage to the ARIA and did acquire the satellite telemetry data 
through the second burn, recording these data on magnetic tape. The data were 
played back to WTR after loss of signal (end of view period). 

The STDN Madrid 26-m station performed successful initial acquisition and 
provided real-time spacecraft 25-kb/s telemetry data to the GSFC POCC, but was 
unable to successfully acquire the uplink. As a result of this, no ranging or 
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Table 1-6. Achieved Injection Conditions 


Cumulat ive 

Parameter Value Probability Pre-Launch 

Level, % Specification 


Semi-major axis, km 

Mean 

7170.271 

50.45 

7150-7186 

Nominal 

7168.7 

30.9 3 



Actual 

7162.770 

0.89 


Recent r ic ity 

Mean 

0.001560 

54.84 

0.0-0.0052 


Nominal 

0.0008 

15.75 



Actual 

0.000667 

9.99 


Inc 1 inat ion , deg 

Mean 

108.09 

51.80 

107.5-108.5 


Nominal 

108.00 

20. 10 



Ac t ua 1 

108.02) 

27.07 


Argument o ! per i gee , 

Mean 

71.7 

61.82 

0-360 

don 

Nominal 

90. 4 

87.68 



Actual 

254.0 

99.86 



commanding could be performed. Madrid reported using a real-time interrange 
vector (1RV) generated by CSFC and reported the following predict angle differ- 
ences (relative to on- track angles) by voice report: 

Initial acquisition: ' dog X,Y angles 

Loss of signal: S deg, X angle, 2 deg Y angle 

Alaska was the next sLation, following the Madrid view period, which was 
scheduled to track, acquire telemetry data, and transmit commands issued from 
the POLL computer. A critical command In the sequence was the switch from the 
ascent omni antenna on the side of the Agena tank to the on-orbit antenna. 

Alaska tailed to detect the Sonsat downlink. A post-launch analysis of 9~m 
antenna angle data showed that the station used the real-time acquisition message 
((IS Ft! had requested the pre-f light nominal be used) containing time and angle 
errors outside the capability of the 9-m antenna system to effect a main-beam 
intercept. The following were found to be Alaska acquisition problems: 

(1) Real-time acquisition data were less accurate than pre-flight 
nomina l s . 

(2) (IS Ft! Network Support Team passed predict message day time group and 
sequence number to station instead of predict type and epoch (needed 
for computer designation) . 
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ACTUAL . 

.89%OSpA^ 


7158.0 7162 . 7 ( 3860 . 7 ) 7170.3 ( 3864 . 8 ) 

( 3858 . 2 ) 

SEMI-MAJOR AXIS, km (nm) 


0.0 .000667 .00156 


7182.0 ( 3871 . 1 ) 



ECCENTRICITY 




ACTUAL 


27.1 % 



107.66 


Figure 3-2. 


108.02 108.09 
INCLINATION, deg 

Monte Carlo Distribution of 
Injection Conditions 


108.41 
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(3) Alaska Inadvertently chose an Intercept point too close to the 

terrain. 

(4) Alaska stayed in manual antenna mode instead of initiating program 
track mode at predicted acquisition of signal (AOS) time plus 30 s 
(standard procedure) . 


During the first five passes, all stations except Ascension Island (ACN) 
had problems in acquiring the uplink to the spacecraft. The ACN personnel were 
trained to initiate "search out" at the exciter control when uplink sweep 
intercepted ground uplink channel frequency at a zero SPE. This may explain why 
ACN was able to maintain uplink lock and uplink commands, while other stations 
were apparently dropping spacecraft receiver lock on previous and subsequent 
passes. 

Other stations showed improvements in their ability to acquire and maintain 
lock in the spacecraft receiver by adopting the following changes: 

(1) Lowering the mod index from O.dg to 0.85. 

(2) Slowing the sweep rate. 


( 1) Using medium loop bandwidth. 

These procedures were implemented during rev 5. 


The POCC computer system functioned well during the launch and early orbits. 
There were only two occasions when the Sigma 5 was rebooted. Erroneous readings, 
which indicated that the computer’s real-time telemetry processor was in a failed 
condition, required the reboots. 


SECTION IV 


ORBITAL CRUISE PHASE 


A. INTRODUCTION 

The Orbital Cruise Phase, defined as being between the Launch and Orbit 
Insertion Phase and the Calibration Phase, had a designated time period of 
2 weeks, starting with the first available STDN ground station contact. In fact, 
there was some overlap between the Launch and Orbit Insertion Phase and the 
Orbital Cruise Phase, where satellite subsystems and total system assessment and 
analysis were scheduled to have been performed. The overlap period spanned 
revs 001 through 005, when the satellite clock was first set and data taking 
began. This followed the successful deployment of the data antennas, sensor 
elements, and other satellite appendages. 

Initially, primary assessment emphasis was given to the Power, Attitude, 
and Data Systems, followed by the Thermal System and, finally, the Propulsion 
System during orbit maneuvers. After sufficient analyses of orbital tracking 
data had been completed, a precision orbit determination was made and the resul- 
tant maneuver recommendations generated. However, because of Attitude Control 
System (ACS) problems, the recommendation was not to perform a maneuver during 
this time period. With the orbit being established, extensive Attitude Control 
System analysis was performed along with the planned sensor engineering 
assessment . 

The sensor assessment was conducted, as planned, in three phases: (1) early 

sensor turn-on; (2) sensor quiet period; and (3) all sensors on. At the end of 
the Orbital Cruise Phase, all sensors were on and the transition to the Calibra- 
tion Phase was effected. Figure 4-1 shows the ascent-to-orbit sequence. 


B. SEQUENCE OF EVENTS 

Two sequences are shown for the planned Orbital Cruise Phase in Figure 4-2 
and Table 4-1. These are the Early Science Mission Sequence and the Planned 
Mission Sequence, respectively. Table 4-2 lists the Actual Mission Sequence. 


C. MISSION OPERATIONS SYSTEM ACTIVITIES 

The MOS activities for this phase were conducted from a "baseline" sequence 
of events (SOE) that was developed specifically for Pre-Launch, Launch, Orbit 
Insertion, and Orbital Cruise Phases by the Mission Control Team (MCT) . This 
third sequence was developed from the information obtained from the two sequences 
of events listed in the previous paragraph. The MCT 15-day sequence is a docu- 
ment containing the detailed planned operations activities for the Orbital 
Cruise Phase. As this detailed SOE is a complete pre-definition of the time 
period, it is impossible because of its size to include it in this report. 
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Table 4-1. Planned Mission Sequence 


1 


i 


Pate 

Day 

Rev 

GMT 

Event 

06/26/78 

177 



F-l day preparations. Countdown start 

06/27/78 

178 


01:05:00 

Liftoff 



0001 


Deploy antennas and solar array 



0001 

to 

0002 


Deploy SAR antennas 



0003 


Set clock and release. Power. Zero 
SMMR. Power subsystem checkout. ACS 
checkout and analysis. First Orbit 
Determination (OD) 

06/28/78 

179 

0016 


Transfer from Reaction Control System 
(RCS) to OACS 



0021 


Begin processing of full-rev data for 
ACS 



0023 


Post-injection orbit solution 



0025 


Load attitude trim commands 




18:00:00 

Maneuver meeting (cal. burn No. 1) 




22:00:00 

Maneuver load to CMS 

06/29/78 

180 

0029 

to 

0042 

14:00:00 

All day: ACS evaluation 

Review maneuver load 




17:00:00 

Orbit solution 




20:00:00 

Orbit Adjust Maneuver Program 
(OAMP) run 

06/30/78 

181 

0043 

00:00:00 

Begin maneuver period. Execute cal. 
burn No . 1 




12:00:00 

End maneuver period 




14:00:00 

Manuever meeting (Orbit Adjust 
(OA) maneuver No. 1) 


Table 4-1. Planned Mission Sequence (Continuation 1) 


Date Day Rev GMT Event 


06/30/78 

181 

0043 

17:00:00 




20:00:00 




22:00:00 

07/01/78 

182 

0057 

15:00:00 



to 

0071 

18:00:00 




20:00:00 




22:00:00 

07/02/78 

183 

0078 

09:00:00 

07/03/78 

184 

0092 

12:00:00 



0094 




0096 




0098 

12:00:00 



0099 


07/04/78 

185 

0100 



0102 

0103 

0104 

0105 

0106 
0109 


Orbit solution 
OAMP run 

Maneuver load to CMS 
Post-maneuver orbit solution 
Final OAMP run 

Review and adjust maneuver load 

Adjusted maneuver to CMS 

Begin maneuver period. Execute OA 
maneuver No. 1 

End of maneuver period. 

Altimeter (ALT) early turn-on 
No. 1 (HAW) 

ALT early turn-on No. 2 (ORR) 

ALT early turn-on No. 3 (MIL) 

SAR early turn-on No. 1 (MIL) 

SAR turn-on No. 2 (GDS) 

SMRR turn-on No. 1 (MAD). ALT early 
turn-on No. 4 (HAW) 

SAR turn-on No. 3 (ULA) 

VIRR turn-on No. 1 (ORR) 

SMRR. turn-on No. 2 (GWM) 

SAR turn-on No. 4 (MIL) 

SAR turn-on No. 5 (ULA) 

SMMR turn-on No. 3 (HAW) 
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Table 4-1. Planned Mission Sequence (Continuation 2) 


Date 

07/05/78 

07/06/78 

07/07/78 


07/08/78 


Day Rev GMT 


Event 


186 0115 

to 

0128 

187 0130 
0133 
0136 
0139 
0141 

14 :00 :00 
22:00:00 

188 0143 00:00:00 

0144 

0145 
0150 

16:00:00 
17:00:00 
20 :00 :00 

189 0158 00:00:00 

to 

0171 12:00:00 

14:00:00 

22:00:00 


ALT on. Begin quiet time (ULA) 

VIRR on. Begin quiet time (AGO) 

SMMR on. Begin quiet time (ULA) 

SASS on. Begin quiet time (MAD) 

SASS HVPS on. Mode 1 (MIL RTC) 

Select cal. burn No. 2 sequence 

Cal. burn No. 2 load to CMS 

SASS operating. Mode 1. ALT on. 
Track 1 (GDS) 

VIRR to operate (GDS) 

SMMR on (ULA) 

Begin normal SAR operation 
Approve maneuver load 
Orbit solution 
OAMP run 

Begin maneuver period. Execute cal. 
burn No. 2 

End of maneuver period. ALT on. 
Track 1. SASS on. Mode 1. VIRR on. 
SMMR on. SAR normal operations 

Select OA maneuver No. 2 sequence 

Maneuver load to CMS 


Tabic 4-1. Planned Mission Sequence (Continuation 3) 


Date 

Day 

Rev 

GMT 

Event 

07/09/78 

190 

0172 

to 

0185 

15:00:00 

Sensors on. Satellite quiet day 
Post -maneuver solution 




18:00:00 

Final OAMP run 




21:00:00 

Predicted post-maneuver ephemerls 

07/10/78 

191 

0186 

to 

0199 

09:00:00 

Begin maneuver period 

07/11/78 

192 

0200 

to 

0214 

12:00:00 

Execute OA maneuver No. 2. End of 
maneuver period. ALT on, Track 1. 
SASS on. Mode 1. VIRR on. SMMR on. 

• SAR normal ops. Satellite quiet day. 
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Table 4-2. Actual Mission Sequence 


Date 

Day 

Rev 

GMT 

Event 

06/27/78 

178 

0009 

17:26:30 

Converter No. 1 off (GWM) 

06/28/78 

179 

0016 

03:31:00 

Attempt wheel capture. Unsuccessful 
(MAD) 



0017 

05:01:00 

Attempt wheel capture. Unsuccessful 
(ACN) 



0019 

09:52:30 

Clock fine adjust (AGO) 



0027 

22:37:30 

Adjust RRW bias V MIL) 

06/29/78 

180 

0030 

03:00:00 

Attempt wheel capture. Unsuccessful 
(MAD) 




03:26:00 

Back to RCS (HAW) 



0042 

23:41:00 

Stopped PMW, Reset RRW. Magnetic 
desaturation off (MIL) 

06/30/78 

181 

0044 

02:30:00 

Disable Right Scan Wheel Assembly 
(RSWA) output 



0051 

15:50:00 

High Mode Reaction Control Cluster 
(HMRCC) heater off (HAW) 



0055 

21:36:00 

PMW to on (ULA) 




21:48:00 

Send first clock offset and first 
clock adjust command (AGO) 



0056 

23:08:00 

Clock adjust command. Normalized 
clock to microseconds (MIL) 

07/01/78 

182 

0060 

03:41:00 

Transfer to OACS (HAW) 




05:08:00 

Back to RCS (ACN) 



0061 

05:37:19 

Right signal processor to off (ULA) 




06:43:30 

PMW to off (ACN) 
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Table 4-2. 

Actual Mission Sequence 

(Continuation 1) 



Date 

Day Rev 

GMT 

Event 



0067 17:51:00 Control Logic Assembly (CLA) power 

supply No. 1 to off (ACN) 


0071 21:17:00 ALT heater bus rapid cycling noted 

(aCO) 

0 7 /02/78 183 0072 00:17:00 PMW to on (CDS) 

00:17:01 CLA power to Magnetic Control Assembly 
(MCA) off (CDS) 

0074 03:09:00 Transfer to OACS (hyd. desaturation) 

(MAD) 

0075 05:23:00 Transfer back to RCS (HAW) 

06:15:00 PMW stop (ACN) 

07/04/78 185 0102 04:14:11 ALT fourth turn-on (HAW) 

04:29:27 ALT turned off (HAW) 

0103 05:27:00 Rerun of SMMR early turn-on No. 1 

(MAD) 

05:31:00 SMMR turned off (MAD) 

05:43:13 SAR early turn-on No. 3 (ULA) 

05:53:53 SAR turned off (ULA) 

06:16:48 VIRR first turn-on (0RR) 

06:22:26 VIRR electronics off (0RR) 

► 0104 07:41:35 SMMR early turn-on No. 2 (GWM) 

07:50:40 SMMR turned off (GWM) 

0105 08:44:36 


08:53:30 


SAR early turn-on No. 4 (MIL) 
SAR turned off (MIL) 


Table 4-2. Actual Mission Sequence (Continuation 2) 


Date 

Day 

Rev 


GMT 

07/04/78 

185 

0107 

12 

05:29 




12 

24:29 



0108 

15 

22:40 




15 

34:25 

07/05/78 

186 

0114 

00 

23:00 




00 

23:01 




00 

23:31 




00 

25:00 



0116 

04 

45:00 



0124 

17 

14:00 

07/06/78 

187 

0130 

03 

09:39 



0133 

08 

21:17 




09 

09:09 



0136 

12 

57:02 



0136 

12 

59:02 



0139 

18 

17:03 




18 

19:18 



0141 

21 

43:59 

07/07/78 

188 

0143 

0’ 

03:11 



0144 

02 

41:49 



0145 

04 

17:11 



0153 

18 

02:00 


Event 

SAR early turn-on No. 5 (CDS) 

SAR turned off (ULA) 

SMMR earjv turn-on No. 3 (HAW) 

SMMR turned off (HAW) 

CLA power on (CDS) 

Left signal processor off (CDS) 

CLA power supply No. 2 off (CDS) 

PMW started (CDS) 

Transfer to OACS; wheel capture (ACN) 

Magnetic desaturation (MAD) 

ALT fifth turn-on (CDS) 

ALT turned off (GWM) 

VIRR second turn-on (AGO) 

VI R electronics off (ULA) 

SMMR turn-on No. 4 (ULA) 

SMMR turned off (MAD) 

SASS enabled (MAD) 

SASS turn-on No. 1 (MIL) 

SMMR turn-on No. 5 (MIL) 

VIRR final turn-on (HAW) 

ALT final turn-on (ULA) 

Connect solar array panels 9 and 10 
(ACN) 


Table 4-2. Actual Mission Sequence (Continuation 3) 


Date 

Day 

Rev 

GMT 

Event 

07/08/78 

189 

0159 

03:24:00 

CLA power on (MAD) 




03:24:05 

CLA power supply No. 2 off (MAD) 



0160 

05:09:00 

Left Scan Wheel Assembly (LSWA) 
processor off (MAD) 

07/10/78 

191 

0199 

23:01:00 

Switched from orbit adjust to orbit 
normal mode (MIL) 


The MCT SOE was a major product generated solely by the MCT before launch, 
and it served well as the baseline operations activities plan in most areas. 

The MCT SOE started at launch minus 4.5 h and ran through launch plus 15 days. 

It contained all of the pre- launch procedures to activate the WTR, STDN, and its 
attendant NASCOM facilities, data flow tests, and operational status checks 
throughout the GDS before launch and subsequent orbits. 

The exceptions to this plan are discussed on a day-to-day basis in the 
following paragraphs. The Attitude Control System was the major exception and 
significantly impacted the SOE, resulting in a cancellation of all orbit adjust 
and trim maneuvers until a later date. SOE integrity was maintained for sensor 
activation and, generally, for tape recorder management. Tape recorder manage- 
ment by the MCT in real time proved to be more complex than estimated. The 
primary reason for this was caused by holding specific attitude data onboard the 
satellite until the GDS could verify its capture had been accomplished. This 
occurred twice. What had been anticipated as a hold of several hours resulted 
in a tape recorder hold of days while the desired attitude data worked its way 
through the GDS and was validated by analysis. 

The MCT SOE was designed to merge into the first Mission Planning SOE 
(MSOE) starting on day 191 (10 July 1978). This schedule demanded timely 
execution of the science or sensor turn-on operation activities, as planned. 

The sensor engineering assessment phases were as follows: 

(1) Early turn-on, with each sensor being individually turned on, 
assessed, and then turned off. 

(2) Sensor quiet period, in which all sensors were activated indivi- 
dually and remained on for mutual evaluation and for assessment 
of RF interference. 

(3) All sensors on for operational assessment. 


4-11 


Tiu* SASS was an exception to this activation process, as the SASS sensor team 
specified a single turn-on cycle, it was the lust sensor to be activated, and 
it remained on until the mission terminated. 

With the orbit maneuvers postponed, it would seem to have diminished the 
total number of activities to be performed. The additional requirement to 
establish an operational GAGS mode placed stringent demands on the time avail- 
able because of the cancellation of the planned orbit maneuvers. All major 
objectives, except the orbit maneuvers and the limited attitude control perfor- 
mance, were successfully completed, and the phaseover to the MSOE at the con- 
clusion of the Orbital Cruise Phase was accomplished as planned. 


I). MISSION PLANNING TEAM OPERATIONS 

1. Mission Planning Software 

Subsequent to launch, satellite problems and the modification of sensor 
operations required some additional revisions to the mission planning software. 
Key among these was the sate 1 lit* thermostat malfunction, which requited the 
development of the SAR operating philosophy in response to both power shortages 
and increased experimenter interest in acquisition of SAR data for spot targets 
rather than limited continuous swaths. The latter Increased the SAR planning 
activity to the point where it was the dominant planning activity, requiring 
both Iterative computer runs and considerable manual intervention. Program 
modifications to accommodate these changes were made in parallel with normal 
flight planning and were incorporated into a third mission build version of 
the software (MOSS 1.2) on 1 October 1978. At the time of the Seasat power 
failure, which terminated the mission on 10 October 1978, development was 
underway on a machine-to-machlne interface with the SAR target identification 
and selection software. 


Several problems occurred in the use of the mission planning software set 
during the mission. The problem mentioned above, where either a change in 
operating characteristics of the satellite or a change in operating philosophy 
occurred, is an obvious one in which the actual requirements upon the operating 
system were not adequately enveloped by the imposed requirements. It was, how- 
ever, recognized prior to launch that such an occurrence was not only possible, 
but quite likely, and the software was designed so that individual programs 
could be changed or added without impacting the balance of the software through 
the use of standardized input/output intermediate files. This was an anticipated 
problem, and was one of implementation rather than wholesale modification. 

A second, and more subtle, problem not fully anticipated was the require- 
ment for a high degree of manual intervention and human decision in the operation 
of the software. Before launch, it was felt that once operational, the software 
could be run in what would essentially be a batch mode with output review and 
iteration. Therefore, the input and review functions could be separated to a 
high degree from the running of the software. In actual practice, however, the 
inherent flexibility of the software and the large number of decision points 
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encountered in progressing through the routines (Figure 4-3) required that the 
' operator not only be fully acquainted with the inputs and the actual science 

requirements on a day-to-day basis, but also that he perform a review function 
on the intermediate files as the run progressed. This effectively precluded the 
; use of data assistants in the operation and required that sequencing engineers 

‘ run the programs. 

} S 

. A third problem encountered in operations Involved a software error in the 

i MCCC IBM 360 computer software which reblocked the CRP for high-speed data line 

: . (HSDL) transmission. Each command or comment in the CRP occupied a single card 

image, with nine card images grouped into a data record for the 1108 to 360 
interface. The 360 blocked the CRP into six-card records compatible with the 
NASCOM HSDLs. A special X-card was included in the CRP to mark the transition 
f i between days, each day starting with a special card bearing processing informa- 

l tion for the CMS designated as the stored program command (SPC) load card. When 

the SPC load card appeared as the first card in a nine-card image record, the 
360 software would initialize. This was normal for the first day in the CRP, 
but if any SPC load card occurred in the first card image of subsequent records, 
the Initialization caused the preceding six cards to be discarded by the system. 
After the initial discovery of this problem, an immediate workaround was 
effected by retransmitting individual days of CRP to avoid recurrence. Once the 
problem was understood, a special stand-alone program was written to determine 
the location of all SPC load cards in the CRP so that dummy comments could^be 
inserted to ensure that the SPC load card did not occur as the first card in any 
record. The problem was finally corrected in the 360 development software about 
30 days after the discovery of the problem. No notification was received that 
the change was effected in the operational system. 

A fourth problem encountered resulted from the insertion of satellite 
commands into the command loads without processing them through the CMS. When 
relatively few of these commands were being inserted from the P0CC, or when they 
were processed through the CMS, they could be checked effectively for timing 
violations, in the former case manually and in the latter automatically by the 
CMS computer. With the addition of approximately 100 heater cycling commands 
a week to the POCC-generated commands, manual checking was insufficient to 
locate all time conflicts. As a result, several times command coincidences 
occurred in the loads. The satellite was mechanized to execute the first command 
recognized for any given second and to ignore any others carrying the same GMT 
time. The command coincidences resulted in, among other things, failure to 
execute a heater bus on command and a SAR no-transmit command, both potentially 
dangerous to the satellite. For any similar mission in the future, the software 
must exist to check for constraints downstream of the last point at which 
unchecked commands are routinely inserted. 



i 





2. SAMDPO Software 

Actual development and testing of SAMDPO continued throughout the lifetime 
of the Seasat mission. All problems encountered in the operation were worked out 
during the operation with the exception of an apparently intermittent problem in 




I 
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Figure 4-3. Mission Planning Team Sequence Software 












































the long-term orbit predicter, which resulted in miscalculations of the position 
of ascending nodes. The source of this problem was never located, but the problem 
could be avoided by checking the SAMDPO output against the tables of predicted 
ascending node positions generated by other software. 

Flight experience showed that the orbital event predictions produced by 
SAMDPO matched extremely well with events observed during the flight. Originally, 
it was thought that the age of the ephemeris data used by SAMDPO might result in 
errors along the track which would be reflected in significant timing errors 
toward the end of the prediction span (roughly orbit epoch time plus 2 weeks). 

To guard against these errors, a time correction capability had been incorpor- 
ated into the CMS so that more recent Code 570 inputs might be used to produce 
daily time corrections known as super time trims. Flight experience was such 
that the use of the super time trim was never required. 

The one drawback to using SAMDPO as an operational program was the excessive 
running time required. Although converting the predecessor program used for 
mission design to an operational program was attractive from a programming stand- 
point, a totally new operational program designed specifically for the Seasat 
mission planning might have been more efficient in the long term. The opera- 
tions plan called for the running of 4 weeks of predicts once qach week. The 
size of SAMDPO and the number of calculations required each run were both so 
large that special operational procedures were required both to avoid excessive 
costs and to ensure that the required runs could be completed each week. Input 
decks were prepared and submitted each Friday afternoon with instructions to 
delay running them until after the files were dumped on the 1108 computer system 
each Friday night. F.ven so, with the program running on a near-dry system, run 
times were never shorter than 3 h although using the full capability of the 
1108 computer system. If the program had to be run on weekend days in competi- 
tion with batch and demand jobs on the system with higher priorities, run times 
of 15 h were not uncommon. For a program of this complexity and size, the total 
cost trade-off between developmental costs and operational costs should be made. 
This trade-off was not necessarily made in the case of SAMDPO. 

The information interfaces generally worked well. Because of the relatively 
fluid nature of flight operations planning, the detailed mechanization of the 
information interfaces was left relatively unfrozen until just before launch, 
and then permitted to evolve into a comfortable working relationship. The 
primary early emphasis was on establishing a single point of contact for each 
information interface and developing the best possible understanding of the 
early orbit operations desired. As it turned out, the SMMR and VIRR low-rate 
sensors had only recommended turn-on and turn-off sequences, several operational 
constraints, and a limited set of assessment requirements. For the remainder of 
the mission, the goal of both sensors was to collect an uninterrupted set of all 
possible data. 

The other two low-rate sensors did have an active interface with the MPS. 

The altimeter was represented for both science acquisition and engineering 
assessment by the Altimeter Sensor Manager of Wallops Flight Center. Engineer- 
ing assessment requirements were identified and reviewed in an expeditious 
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manner and presented no problems , as was also tbe case with altimeter group 
commands. A calibration algorithm was developed several months before launch 
and was implemented in the mission planning software. Altimeter science acquisi- 
tion requirements were modified during flight in response to suspected altimeter 
problems and the thermal control thermostat failures. In each case, the nature 
of the sequencing changes had been anticipated before launch, and the appro- 
priate command triggers and routines existed in the software. It remained only 
to negotiate the details of the changes and to implement them. As only command 
algorithms were at issue, no extended interaction was required, and the inter- 
face was effected entirely through black phone with datafax backup. 

The SASS presented more of a problem, as the science requirements included 
approximately 300 sensor mode changes each week to accommodate specific coverage 
of selected targets. These changes were transmitted from the Langley Research 
Center to the MPS by datafax each week for the operational period several weeks 
ahead. The mode changes were then reviewed for consistency and manually 
inserted into a computer input file. Machine checking identified only syntax 
errors, not input errors. As a result, during the mission several mode changes 
at erroneous times slipped into the CRP. This should have been a machine-to- 
machine interface with manual review and override to eliminate errors. 

The SAR group was the only sensor group with full-time representation at 
JPL. As a result, information flow between the SAR and the MPS occurred daily 
on a face-to-face basis, which was fortunate because, ultimately, the SAR plan- 
ning became the largest single activity of the MPS. Before launch, each SAR 
member had identified SAR targets of interest and time periods for data acquisi- 
tion over each target based on the pre- launch nominal orbit. With the delay in 
orbit adjust maneuvers because of the attitude control anomalies subsequent to 
launch, the pre-flight SAR planning was invalid. During the early portion of 
the flight mission, SAR experiment requests were hand-generated for a nominal 
six 10-min SAR passes each day, but the planning guidelines called for issuing 
the SAR transmit command at 10-deg elevation or station AOS, whichever was pre- 
dicted to occur later. This meant that the information required across the 
interface between the SAR and the MPS was the revolution number and SAR ground 
station requested plus any special instructions for engineering assessment 
commands. As the minimum power period for the satellite approached, however, 
the SAR operating time was curtailed to conserve power. By this time, the first 
SAR processing of data had convinced the experiment team members that SAR passes 
much less than 10 min in duration were of value if they included specific targets 
of interest. 

As a result, the normal mode of operation during the minimum power period 
became the acquisition of from two to eight SAR passes varying in duration from 
2 to 6 min each day. The information passing across the interface at this point 
became the GMT time of turn-on and turn-off, the SAR ground station requested, 
and any special assessment commands. While capability to accommodate this form 
of input existed in the mission planning software, problems were encountered. 

Many targets of interest were at relatively low elevation angles within the SAR 
station passes. Errors in specifying the GMT times, which were due to differ- 
ences in orbit solutions used in the target selection and CRP preparation 
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processes resulted In requested SAR on and off times lying outside ground station 
view. The impact to the MPS was that these occurrences had to be flagged as 
planning violations, reviewed, manually adjusted, and rerun through the software. 
This added an iterative loop both in the software operation and across the 
information interface not envisioned before launch. The problem created became 
increasingly severe after the end of the minimum power period when as many as 
12 SAR passes each day over specific targets of interest would be routinely 
requested. At the time of mission termination, effort was in process within the 
SAR experiment team to program the target selection algorithm in the 1108 com- 
puter system in terms of delta time with respect to time of ascending node. 

This program was intended to produce a computer file of SAR pass requests that 
could be accessed by the planning software so that the GMT times could be 
generated without ground station mass violations. There is every reason to 
believe that, had development of this machlne-to-machine interface been completed 
and used, SAR planning would have been greatly simplified. 

The information interface with SPAT never materialized as envisioned 
before launch. Originally, it was intended that one SPAT member would be 
located at JPL full-time to represent SPAT within the MPS. This representative 
was to be in daily contact with the main body of SPAT at GSFC to serve as a 
liason for passing planning information other than the MPS deliverables to GSFC 
and near-real-time performance information to the MPS. As a result of, first, 
the attitude control anomalies, then the heater thermostat failures, and 
finally the low power problem, the SPAT representative was required to remain 
at GSFC to assist in real-time data analysis and command through September 1978. 
The representative had spent about 3 weeks in residence at JPL at the time of 
the mission termination, most of which was devoted to the installation of the 
LMSC power prediction program on the 1108 computer system. During his stay 
at GSFC, MPS contact with SPAT was largely through black phone contacts with 
the representative. While this was adequate as a temporary measure, informa- 
tion flow between the MPS and GSFC would have been much improved if the SPAT 
representative had been available for involvement in the planning process on a 
daily basis. One of the most glaring Seasat deficiencies was the lack of any 
mechanism other than the SPAT representative’s residence at JPL for returning 
performance and command information to JPL on a timely and rigorous basis. The 
LMSC daily status bulletins, initiated considerably after launch, were of con- 
siderable help in providing this information, but were irregular in delivery 
and were often incomplete. 


E. SYSTEMS PERFORMANCE 

1. Satellite Performance 

This section provides a summary of spacecraft systems performance during 
the orbital cruise phase of the mission. Plans to produce a monthly satellite 
performance analysis report (described in JPL internal document 622-42, Seasat-A 
Spaceflight Operations Plan , May 1978) did not materialize because of early 
problems described here. 


4-17 


Wheel captures were attempted on revs 16 (MAD) and 17 (ACN), but large 
attitude errors forced a return to the Reaction Control System (RCS) In each 
instance. 

In an attempt to minimize the attitude errors , the Roll Reaction Wheel 
(RRW) bias was changed on rev 27 (MIL), and wheel capture was again attempted on 
rev 30 (MAD). On rev 30 (HAW), the attitude errors again became excessive, and 
the satellite was returned to the RCS. 

On rev 42 (MIL) the Pitch Momentum Wheel (PMW) and the RRW were stopped, 
and magnetic desaturation was turned off. The Right Scan Wheel Assembly (RSWA) 
output was inhibited on rev 45 (MAD). The High Mode Reaction Control Cluster 
(HMRCC) heater was turned off on rev 51 (HAW) for power conservation. On rev 55 
(MIL), the PMW was turned on. 

Another attempt was made to transfer to the Orbital Attitude Control System 
(OACS) on rev 60 (HAW), but again wheel capture was denied by excessive attitude 
errors, and the satellite was returned to the RCS on rev 60 (ACN). The right 
signal processor and the PMW were turned off on rev 61 (ULA/ACN) , and Control 
Logic Assembly (CLA) power supply 2 was turned off on rev 67 (ACN). 

Rapid cycling of the altimeter heater bus was observed on rev 70 (AGO) and 
again on rev 71 (MIL). The cyclic period was approximately 10 s. The appropriate 
LMSC subsystem engineers were alerted to this condition. 

In preparation for another attempt to transfer to the OACS, the PMW was 
turned on, and CLA power to the Magnetic Control Assembly (MCA) was turned off 
on rev 72 (GDS) . Transfer to the OACS in the hydrazine desaturation mode occurred 
on rev 74 (MAD). By rev 75 (HAW), the attitude errors had become excessive, and 
the satellite was transferred back to the RCS. PMW stop was executed on rev 75 
(ACN), and the magnetic desaturation mode was inhibited on rev 76 (ULA). 

A test was conducted on rev 88 (MAD/ORR) to gather more data on the attitude 
problem. The gyros were turned on during rev 86 (GDS) and permitted to stabilize 
for two orbits. The forward gyro started, and the Scan Wheel Assembly (SWA) 
pitch and roll was enabled. With the spacecraft on gyros, the left and right 
SWAs were alternately enabled for one revolution each. At the conclusion of 
this test, attitude subsystem efforts were suspended until rev 114 (GDS). 

The sensor engineering assessment phase began on rev 94 (HAW) , and ended on 
rev 145 (ULA). During this period, the sensors were individually cycled on and 
off at the direction of the applicable sensor representatives. 

The initial turn-on for the altimeter was aborted when the station was 
unable to receive satellite data because of a ground equipment nroblem. Sub- 
sequently, the altimeter was turned on and off a total of five times, with final 
turn-on occurring on rev 145 (ULA). 

The SAR was cycled on and off five times. During the first on period, the 
pulse repetition frequency (PRF) switch was set to position 4 to enable the ground 
equipment to lock on the data. 
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The first turn-on attempt for the SMMR occurred on rev 102 (MAD). The 
Instrument was not in the proper mode to accept the turn-on sequence au formu- 
lated, and pass time expired before a new command sequence could be initiated 
to the spacecraft. The SMMR was subsequently turned on and off, without inci- 
dent, a total of three times and was ultimately turned on during rev 136 (ULA) . 

VIRR on and off sequences were routinely acccmplished twice during this 
phase. The final turn-on occurred on rev 144 (HAW). 

With no preliminaries, the SASS was enabled on rev 139 (MAD), and was 
turned on during rev 141 (MIL). Figure 4-4 shows a timeline of the sensor 
on /off sequences during the engineering assessment phase. 

Following the engineering assessment phase, power considerations required 
that solar array panels 9 and 10 be connected to the system. This was accom- 
plished on rev 153 (ACN). 

The sensor on/off sequence was interrupted by another attempt at wheel 
capture. CLA power on, left signal processor off, CLA power supply 2 off, and 
PMW start were all accomplished on rev 114 (CDS). The spacecraft was trans- 
ferred to the OACS on rev 116 (ACN) . Magnetic desaturation was initiated on 
rev 142 (MAD). With acceptable stability demonstrated, CLA power on and CLA 
power supply 2 off were sent on rev 159 (MAD). LSWA processor off was sent on 
rev 160 (MAD), and the vehicle was transferred from the orbit adjust to the 
orbit normal mode on rev 199 (MIL) . 


2. Ground System Performance 

Ground system operations for this time period began with rev 6 and extended 
through rev 199 (days 178 to 192). This phase of the operations was the most 
active of the mission. Normally, this phase was planned to begin after rev 3, 
when the satellite clock was reset to current GMT. The clock was not set to 
GMT until rev 5 (AGO), completing the configuration of the data subsystem, and 
was the last planned step before the start of the Orbital Cruise Phase. 

Scheduling for the Orbital Cruise Phase was performed and submitted 
according to the plan outlined in the Space Flight Operations Plan (SFOP). A 
total of 295 STDN passes were planned and scheduled. On an average, this was 
slightly over 22.5 passes each day, with the peak day being launch day with a 
total of 37 passes. By the time the Orbital Cruise Phase began with rev 6, 

22 passes had been completed (refer to Section III). A total of 295 passes were 
scheduled and 289 were conducted as scheduled. The reasons for the loss of the 
six passes (approximately 2 percent) were as follows: 

(1) Sky lab . Two passes lost to critical Skylab coverage. 

(2) Communications . Two passes lost because of a 3760 computer problem 
and a wide band data line (WBDL) problem. 
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(3) Spacecraft Command Encoder . One pass cancelled because of red 
Spacecraft Command Encoder (SCE). 

(4) Sigma 5 Computer . One pass cancelled to give time to Implement 
SEAC software Version 10.005. 


The scheduling during this phase proceeded very well; however, this high 
activity had an adverse effect on securing enough Sigma 5 time to perform play- 
back of TELOPS tapes to the Attitude Determination System (ADS) , post- real- time 
analysis of TELOPS tapes, and other background processing required to support the 
mission in real time. 

TELOPS /IPD was also specifically scheduled to provide the Seasat/POCC */ith 
quick-look playback tapes. These tapes and orbits were pre-deflned to evaluate 
the characteristics of the ACS when the satellite was under the control of the 
OACS. Additionally, data were also to be processed, analyzed, and fitted to the 
predicted power usage curve, which had been generated by the LMSC power program. 

As the LMSC attitude programs could only be completely tested by using 
actual satellite data, the early receipt of TELOPS tapes was vital to the veri- 
fication of these programs. During these first days of the mission, documented 
records of the delivery of tapes from TELOPS were not maintained. Late delivery, 
coupled with the satellite ACS problems, had a severe impact on real-time failure 
analysis and the planned systems analysis of the attitude control and power 
systems. 

The POCC Sigma 5 computer was responsible for the largest number of fail- 
ures during this mission phase. During the 289 real-time passes performed, there 
were 109 various discrete failures or real-time data losses. The Sigma 5 was 
re-initialized during real-time passes 47 times. In addition to chese single 
"reboots," eight additional "double reboots" were required. Finally, two com- 
plete system reloads were required during this phase. 

.iormally, the first action taken to correct a problem was to initiate a 
Sigma 5 reboot. Therefore, some of these ’*e-initialization attempts to correct 
a problem were misdirected at the Sigma 5. Double reboot was the term used when 
tne first re- initialization attempt did not clear the data processing problems 
and a second Sigma 5 initialization was required immediately after the first 
attempt. 

At two different times, a complete system reload was performed. The charac- 
teristics of the Sigma 5 and SEAC software were such that reboots or failures 
occurred in groups over a period of time. Because of frequent reboots over a 
short period of time, a system reload would be performed. A system reload 
required about 3 h, and had to be carefully planned to re-establish the unique 
data processing subroutines (procedures) used by the MCT and SPAT to analyze the 
satellite data in real time. It appeared that perhaps the Sigma 5 core was 
becoming fragmented, impeding data processing. This problem was not specifically 
identified on the next SEAC software (Version 10.005), which was Implemented on 
the last day of this phase (day 191). 


4-21 


On# documented Interface problem that continued and often resulted In a 
Sigpta 5 reboot was the failure of CRT and keyboard devlcee. These Interface 
failures, which were hardware failures at the CRT/Slgma 5 Interface, did not 
normally affect the on-going data processing of the SEAC program, but were to 
clear the device and return it to an operational status after a reboot was 
required. Another Sigma 5 Interface that failed on some occasions was the 
POCC Data Set Controllers (DSCs). There were two DSC failures in this phase. 

A DSC failure was difficult to distinguish from NASCCM data line failures. There 
were also five failures in the NASCON segment of the ground system during thla 
phase . 


The ADS/Slgma 5 Interface also precipitated numerous Sigma 5 reboots, 
although only one ADS failure was clearly recorded on a real-time pass log. 

This failure typically manifested Itself at the conclusion of a Sigma 5- to- ADS 
transmission. During these transmissions, the Sigma 5 stripped out eight param- 
eters from the TELOPS playback tapes, built data records, and transmitted these 
records to ADS through an HSDL. The Sigma's telemetry data processing following 
this task would not function properly (for real-time operations) unless It was 
re-inltiallzed after a non-real-time ADS transmission. This Interface problem 
was corrected by implementing ground system operating procedures in the Seasat 
POCC. 


A second HSDL /Sigma 5 Interface was the CMS/Sigma S interface. While this 
Interface was not planned to be exercised extensively during this phase, the 
HSDL/CMS Interface frequently failed throughout the life of the mission. The 
backup to the HSDL was hand delivery of the CMS tapes to the POCC. Because of 
the close proximity of the POCC and CMS facilities, the HSDL failure was not 
investigated in any depth. 

The last category of direct Sigma 5 and POCC interfaces to be discussed is 
the Orbit Determination System (ODS) interface. Two problem areas reported in 
the ACMO's completed pass logs were range tapes and satellite tracking predicts 
at the STDN stations. The ranging tape was generated by ODS to be used by the 
Sigma 5 Tlmecal Program. The output of this program was used to determine the 
satellite clock offset from actual GMT. One documented range tape failure 
occurred in this phase. However, because of the turnaround time required to 
obtain a new tape from the ODS, only one failure created a significant problem 
in producing time offsets as planned every 24 h. A delay resulting from a range 
tape problem had a rippling effect through subsequent data processing by TELOPS 
and other users of this clock offset information. 

There were two ODS (predict) problems in this phase: (1) the predicted 

AOS/LOS times on the predict sets being used by the STDN stations were in error 
by more than several seconds, and (2) the orbit numbers on the predicts used by 
the stations were offset by one orbit for several days. During the time when 
the AOS times were incorrect (from several seconds to approximately 1 min), the 
MCT was operating in a single tape recorder mode. Inaccurate predicts caused 
delayed acquisitions and missed opportunities to perform tape recorder dumps 
over planned STDN stations. The orbit number errors required an excessive 
amount of additional bookkeeping to correct orbit numbers when this very 
valuable time was needed to perform real-time problem analysis in the POCC. 
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The second most significant category of failures was those originating at 
the STDN stations. A total of 42 discrete failures resulting in data losses 
occurred during this phase. The most common failure type was again software 
related, as over 50 percent of the failures were either SCE or Digital Data 
Processing System (DDPS) failures. The SCE failures, of which there were 13, 
generally occurred at random throughout the network. However, the DDPS failures, 
of which there were nine, were primarily concentrated at ULA and were DDPS 
program 3 failures. 

Another category of failures was those where the station's receiver dropped 
lock because of a mode change on the satellite or because the initial receiver 
configuration was not compatible with the satellite downlink. Following launch, 
all STDN stations had difficulty in maintaining two-way lock and in commanding 
Seasat. With the stations' assistance, particularly MIL, an acquisition pro- 
cedure was developed in real time that proved to be very successful. This new 
STDN procedure changed the nominal sweep rates and uplink mod/index levels as 
stated in the NOSP standard acquisition procedure. There were several data 
losses related to changing RF modes on the satellite; these were the 800-kb/s 
data playback mode and the ranging mode. Data losses because of switching to a 
800-kb/s data playback mode diminished over a very short time period. This 
problem appeared to have been procedural, and was corrected by the STDN station 
operators. Five data losses occurred during this phase following ranging on/off 
commands and data losses continued to occur at random throughout the mission. 

This problem was not Investigated in any depth by the Seasat Project to deter- 
mine if these data losses were satellite- or station-related problems. 

In summary, there was a discrete system failure for every 2.7 orbits. In 
addition, there were interface problems that spanned part or all of the Orbital 
Cruise Phase and were not relevant to an orbit-by-orbit accounting. No other 
data are at hand to compare with these failure points. While the failure rate 
seems to be much higher than in other mission periods, the total mission activity 
was also at its peak during this phase and more demands were placed on all 
elements of the ground system. Problems were not an unexpected factor in any 
case, and almost all were corrected quickly and expertly by the responsible 
personnel in the ground system, as had been expected before launch. In the 
areas where immediate solutions were available, procedural workarounds were 
quickly implemented. All major planned events were executed except the orbit 
maneuvers. The MCT was prepared to conduct these maneuvers, if required. The 
transition to the Calibration Phase from the Orbital Cruise Phase was completed 
as planned. 
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SECTION V 


CALIBRATION PHASE 


A. INTRODUCTION 

This •action discusses the mission operations activities during the 
Calibration Phase o£ the ole? Ion. The Calibration Phase is defined as the time 
period in which the required calibrations for the spacecraft sensors were per- 
formed. The primary purpoae of this phase was to demonstrate the operational 
capabilities of the spacecraft and covered the time period of 30 to 90 daya 
after initial checkout. 


B. SEQUENCE OF EVENTS 

The sequence of events for this phase of the mission was the standard 
Mission Sequence of Events (MSOE). As described in Section I. the MSOE was the 
final product of the Mission Planning Team (MPT). It was the responsibility of 
the Mission Control Team (MCT) to review, update if required, and Implement 
the sequence as received from the MPT. Although the MCT maintained a very active 
interface with the MPT, the MCT had very little visibility with the other MPT 
interfaces. It was these Interfaces that determined the science mission profile 
during the Calibration Phase. In summary, the MCT focused on the conduct of the 
mission while the MPT coordinated the calibration outputs. 


C. SENSOR CALIBRATION 

Five sensors were carried aboard the Seasat spacecraft. The Radar Altim- 
eter, Scatterometer (SASS) , and Syntlstic Aperture Radar (SAR) were active 
radiators, and the Scanning Multichar, iel Microwave Radiometer (SMMR) and Visual 
and Infrared Radiometer (VIRR) were passive receivers. Each sensor had differ- 
ent coverage characteristics, depending on the pointing, f ield-of-view, and data 
handling requirements and, for the SASS, the Doppler velocity between the space- 
craft and the ground points. The sensors were secured to the spacecraft so that 
changes in coverage occurred only as a result of changes in the spacecraft posi- 
tion or altitude. The only exception to this was the altimeter, which sensed 
conditions at the subsatellite point normal to the surface and independent of 
nominal spacecraft oscillations. 

The swath for each sensor was defined by the ground cross-track area 
produced by the censor’s receiving f ield-of-view. The ground pattern and swath 
for each sensor is shown in Figure 5-1. The ground trace of each sensor swath 
is shown for one orbit on a Mercator projection in Figures 5-2 through 5-5. The 
calibration objectives for the sensors are described in the following paragraphs. 
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Figure 5-1. Seasat Instrument Coverage 
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1. Synthetic Aperture Radar Calibration 

The objective of the SAR experiment was to demonstrate the capability of a 
satellite-mounted SAR to obtain high resolution ocean surface imagery* monitor 
coastal processes, chart ice fields, detect Icebergs, and obtain land imagery. 

The engineering assessment of the SAR was conducted to evaluate SAR 
inflight performance and to ensure data quality. The SAR experiment team repre- 
sentative provided the SAR pass selection Inputs to the MPT. Operations during 
the first weeks of the mission proceeded as planned, and included the following 
accomplishments: 

(1) SAR operate/data link on without radar transmitter permitted 
signature with radar noise at each SAR site. 

(2) Data link coverage near station zenith permitted full cuts 
through the spacecraft antenna. 

(3) Passes over corner reflectors were recorded and analyzed. 

The normal operation of SAR electronics and data link was confirmed. Areas 
of evaluation were proper command responses, expected telemetry values, operating 
temperatures, and transmitter power. The SAR performance evaluation effort 
covered the following three areas: 

(1) Functional operation of the system elements. 

(2) Measurement of performance parameters and comparison of predicted 
values. 

(3) Assurance of imaging quality. 

These activities took place at: (1) the POCC by the Satellite Performance 
Analysis Team; (2) STDN SAR sites by SAR team personnel; (3) JPL by review of 
telemetry data; and (4) JPL by processing and image analysis teams. Table 5-1 
summarizes the status of performance evaluation. 


2. Radar Altimeter 

The objective of the altimeter calibration was to evaluate three basic 
altimeter geophysical parameters: 

(1) Altitude of spacecraft above sea surface (h) . 

(2) Sea state as measured by the average height of the highest 
one-third of the waves in the antenna swath 

(3) Sea state backscatter coefficient (o°). 
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Tabic 5-1. Seacct SAR Engineering Ascecament Performance Evaluation 


Performance 

Evaluation Activity 

Status 

Functional Verification 



Satellite elementa 

SPAT participation at POCC 

Completed 


Response to commands 

Verified 


Telemetry at expected 
values 

Verified 

System elements 
through demodulation 

CDS observer 

MFR and demodulation lock 

3 sites visited 
Verified 


Offset video echo and STC 

STC bias 


Simulator RG compression 

Observed 


Rechlrp 

Observed 


Corner reflector echo 

Not seen 

End-to-end system 
through SDPS 

SDPS processing of point 
target returns 


System Parameter Values 



Satellite subsystem 
amplitude stability 

Pre-launch analysis of test 
data 

Complete 

Satellite thermal 
characteristics and 
transmit power 
stability 

Plots of sensor and data 
link temperatures and 
transmit power versus time 
from telemetry 

Complete 

Data link pattern 
and horizon mask 

MFR AGC versus look angle at 
CDS 

Incomplete 

SAR antenna pattern 

L-band power (with AAFE 
receivers) versus look angle 


End-to-end SNR 

Offset video signal and 
noise at GDS 

Complete 
3 sites 

Image spectra 

Computer analysis of 
digitized signal film 

Plans only 

Image performance 
parameters 

Estimate values from images 
with point targets and 
compare with predicted values 
and tolerances 

Plans only 
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Table 5-1. Seasat SAR Engineering Aasesament Performance Evaluation 
(Continuation 1) 


Performance 

Evaluation Activity 

Status 

Image quality 

Establish and verify proce- 

Partially 

assessment 

dures for HDRRs, tapes, and 
film and assess parameter 
values and general image 
quality 



To implement these altimeter evaluations. Seasat-derived altimeter param- 
eter values were compared with independently observed values. Surface truth 
data obtained from the North Atlantic calibration area. Gulf of Alaska, North 
Sea, and Joint Air-Sea Interaction Experiment (JASIN) area were used along with 
laser and S-band observations from Bermuda overflight passes as the primary data 
set. By obtaining Independent measurements of the altimeter parameters, the 
Instrument bias and accuracy were determined. The calibration activity was 
divided into three phases. 

a. Phase I . This phase was based on the first available data processed 
in the shakedown mode to accomplish early assessment of sensor performance. 


b. Phase II . This phase encom, tssed data collection activity performed 
during the Bermuda overflight period in September 1978. The use of altimeter 
data minimized the need for geoid and ocean topography models. The resulting 
altimeter h-bias information was good to the submeter level. 


c. Phase III . This phase covered a definitive evaluation period where 
the ultimate accuracy and data processing algorithms were assessed. The time 
frame for this phase extended until mission termination. The objective of this 
analysis was: (1) to determine the bias in the altimeter measurements with an 

accuracy of 10 to 20 cm. and (2) to demonstrate that Seasat altimeter Hjyj 
measurements and o° measurements met the design specifications. 


There were three possible methods for determining the bias in the Seasat 
altimeter measurements: 

(1) Direct Overflight . This method required the satellite to pass 
directly over the tracking laser. 

(2) Short Arc Triangulation . This method required that the satellite 
be tracked by three or more lasers during a single pass over the 
calibration area with the altimeter operating. 
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(3) Global Lone Arc . This method evaluated the altimeter height bias 

using orbits determined from the globally distributed Tranet Doppler 

system. 

Command sequences required to calibrate the altimeter were provided to the 
MCT by experlmentors through the MPT. Following orbit adjust maneuvers at 
22:39:00 GMT on day 250, altimeter calibration date were gethered for 30 days 
on Bermuda (BDA) overflight passes (every third day) end are listed below: 


Rev No. 

Time Period 

1117 

256/0254-0309 

1160 

259/0306-0321 

1203 

262/0318-0333 

1246 

265/0330-0345 

1289 

268/0345-0400 

1332 

271/0357-0412 

1375 

274/0409-0424 

1418 

277/0421-0436 

1461 

280/0433-0448 

Seasat 

Failure 

283/0426 


BDA was required to support these passes and gather as much Doppler data as 
possible. As the real-time, 25-k/bs data were not available to the POCC from BDA 
and MIL, trailing passes (overlap of approximately 3 min) were also scheduled. 

So that BDA could gather maximum Doppler data, MIL was required not to bring up 
their uplink carrier until BDA’s loss of signal, which did not leave enough time 
for a tape recorder dump (7 min, 12 s required). To achieve this, the tape 
recording cycles were readjusted by the MPT. 


3. SASS Calibration 

This instrument provided closely spaced grid measurements of surface wind 
speed and direction in the range of from 4 to 50 m/s. This could be Inferred by 
sensing the average radar cross section or scattering coefficient (o°) or the 
rough ocean surface. Therefore, the satellite instrument had to be calibrated 
in terms of o°. 
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The measurements made by the satellite instruments were compared to the 
valves of obtained by a highl* accurate SASS installed on an underflying air- 
craft. Therefore, the absolute calibration of the SASS was dependent on three 
major elements: 

(1) Calibration of the underflight instrument. 

(2) Underflights themselves. 

(3) Subsequent data comparison. 

Metal spheres of different radii suspended from balloons and a helicopter 
were used to calibrate the underflight instrument. The value of o° for a sphere 
is easily calculated and varies with the radius squared. Range was accurately 
determined using a Wallops Flight Center (WFC) tracking radar. Since path 
losses were negligible, the o° could be readily computed. The underflight 
instrument was calibrated to an accuracy of >0.3 dB. 

The underflights were conducted between 23 August and 30 September 1978, 
primarily in the North Atlantic and Gulf of Alaska, as part of the JAS1N and 
GOASEX programs, respectively. The underflight instrument was installed on the 
NASA/JSC C-130, NASA-929 aircraft. Table 5-2 lists the data set used for the 
SASS calibration. 


4. Scanning Multichannel Microwave Radiometer Calibration 

The principal requirement for the SMMR was to provide all-weather global 
measurements of sea surface temperature to a precision of 1 to 2 K for oceano- 
graphic and climatological research. Another requirement was to use microwave 
brightness measurements for high wind determination to complement and extend the 
SASS measurements. The instrument was calibrated on the ground before launch at 
JPL. No in-flight calibration activities were conducted. 


5. Visual and Infrared Radiometer Calibration 

The VIRR provided low resolution (9 by 9 km) feature recognition and cloud 
position information, clear air sea surface temperature (±0.5 K) , and cloud top 
brightness temperatures in support of the microwave instruments. No inflight 
calibration activities were conducted. 


D. FLIGHT SYSTEMS PERFORMANCE 

1. Spacecraft Performance 

All sensors were operational at the beginning of day 188. The altimeter, 
SMMR, SASS, and VIRR were operating at 100 percent duty cycle, while the SAR 
was operating at 45 percent duty cycle. Table 5-3 summarizes the events. 


5-11 


Table 5-2. SASS Calibration Data Sat 


Location 

Date 

Rev 

Forward Beam 
Calls 

Aft Beam 
Cells 

Polarization 

Wind 

Speed, m/s 

JASIN 

8/23 

0823 

1/5-7 

2/7-12 

Both 

10 


8/25 

0848 

4/1, 2, 4 

3/1, 2, 4 

Both 

>10 


8/29 

0905 

4/4-8 

3/3-7 

Both 

7 



0906 

1/2-10 

2/3-12 

Both 

7 


9/04 

0991 

4/3-11 

3/2-9 

Both 

8 



0992 

1/1-10 

2/2-11 

Both 

10-20 

GO AS EX 

9/14 

1140 

4/1-6,13,15 

3/1-5,13,15 

Both 

30-35 


9/17 

1183 

4/1-6,13,15 

3/1-5,13.15 

Both 

30 


9/19 

1112 

1/1-9,13,15 

2/1-9,13,15 

Both 

30 

East Coast 

9/28 

1339 

1/1-8,13,15 

2/2-8,13,15 

Both 

8-14 

USA 








9/30 

1367 

4/3-12 

3/2-12 

Both 

15-30 


The SASS baseplate temperatures were out of specification on the low side 
up to 16°C an estimated 90 percent of the time as manual cycling of the heater 
bus began on rev 416 (day 206). However, this condition had no effect on the 
SASS operation. 

There were several planned occasions when some of the sensors were 
restricted in their operations: 

(1) During a spacecraft low power period (days 242 to 252), the VIRR 
electronics were commanded off to conserve power. The SAR was oper- 
ated only at 1 percent duty cycle rather than 7 percent as planned 
for the same reason. 

(2) The SASS and altimeter were placed in non-operational modes during 
spacecraft maneuvers. 


2. OACS Performance 

Anomalous OACS behavior was first observed on rev 17 (ACN). Backup 
attitude control modes were available to permit the on-schedule initial power-up 
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Table 5-3. Summary of Events 


Number 

Day 

Rev 

Comments 

1 

222 

641 

VIRR detector temperature exceeded limit of 35*C 
(95*F). VIRR was commanded off. 

2 

229 

681 

VIRR detector temperature limit changed to 38*C 
(100°F). VIRR was commanded on. 

3 

240 

890 

VIRR motor stalled. No data was output from the 
sensor. 

4 

240 

891 

Spacecraft bus voltage fell below 22 Vdc. Internal 
fault detector turn ALT off. 

5 

240 

895 

ALT was commanded off. 

6 

240 

897 

Several attempts for next 110 revolutions were 
made to command VIRR motor on. No success. 

7 

244 

953 

ALT was commanded on for 60 percent of the time in 
track mode ard 40 percent of the time in standby 
mode until rev 1255 (day 265). 

8 

247 

1000 

SMMR cold horn temperature. 157°C (315°F) limit. 
Defined new limit of 160°C (320°F). 

9 

253 

1073 

Modified and used the sequence to command VIRR 
motor on. On 2 occasions. VIRR motor made one 
revolution and stopped. 

10 

255 

1105 

Modified and used new sequence to command VIRR 
motor turn-on. Motor started running. 

11 

256 

1115 

VIRR motor stopped again. Subsequent attempts to 
start motor again failed. Engineering analysis 
concluded that the motor stalling could be caused 
by a particular inclusion in the gear drive, a 
failure of the bearing supporting the shaft, or in 
the motor itself. 

12 

265 

1255 

New operational mode for ALT; test mode over land 
and track mode over water. 
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and checkout of the sensors. The control ayatem performance from rev 130 
until final control ayatem trim on rev 377 was adequate. Workaround operations 
were developed to mitigate the effects of anomalous behavior on the OACS 
performance. 

Five orbit adjusts were performed to support development of a precise orbit 
over Bermuda for altimeter calibration. The orbit adjusts required switching 
from the momentum attitude control system to the hydrazine attitude control sys- 
tem, and then back to the momentum system. Control in each mode and switching 
between modes was performed without operational problems. Orbit adjust maneuvers 
were performed during the following revolutions? 


Maneuver 

Rev 

1 

701-705 

2 

744-749 

3 

819-821 

4 

862-864 

5 

1072-1073 


After an initial workaround was developed, the OACS performed admirably 
through all orbit adjust maneuvers until spacecraft terminal power failure over 
the Orrorai, Australia tracking station. 


3. Power Performance 

All electrical power systems performed properly and no hardware failures 
occurred up to the final rev (1303), when the failure took place. Power con- 
sumption in the spacecraft loads was greater because of OACS anomalies and ther- 
mal control system thermostat failures; however, bus subsystem loads were in the 
predicted ranges. Also, solar array output power was within the predicted 
ranges. During out-of-specification conditions on rev 891, power system control 
was maintained, including regulation, and no damage to the batteries was indi- 
cated. No damage to any other hardware was evident as a result of the out-of- 
specification voltage condition. No evidence was available to suggest power 
subsystem design error or malfunction as the cause of the low voltage condition. 
The out-of-specification low voltage condition was attributed to an LMSC Space- 
craft Performance Analysis Tei (SPAT) performance lapse. This performance lapse 
was addressed by LMSC and resuiced in extensive operational changes and record 
keeping and personnel revisions. 

During the final revolution of the spacecraft, a massive short circuit 
developed. The power system maintained normal sensor input for approximately 
1 h after the onset of the short circuit, at which time sensor telemetry func- 
tions and spacecraft S-band telemetry downlink ceased. 
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E. GROUND SYSTEM PERFORMANCE 

1. POCC Computer System 

a. Hardware . There were no significant hardware problems, primarily 
because of the ample redundance built into the system. Although some passes were 
conducted using a backup Sigma 5 computer because of maintenance work being per-* 
formed on the prime system, it had no adverse impact on spacecraft operations. 

The duration of this maintenance work was approximately 3 to 4 hours a week. 


b. Software . Significant problem areas in the software were as follows: 

(1) Tlmecal . This segment of the software was used to compute the 
offset and drift of the spacecraft clock. Depending on the 
type of data being processed, the program often produced 
erroneous results. The impact of this problem was a backlog 
accumulation of clock offset drift messages that could not be 
computed on time. 

(2) Limit Checking. The programs were used to indicate the measure- 
ments that were not within the set of pre-specif led limits. 

The programs functioned properly, but the format of the message 
transmitted to indicate a certain measurement was beyond normal 
limits was inadequate. 

(3) Data Transmission to ADS . When transmitting data to ADS, the 
Sigma 5 computer failed occasionally and had to be 
re-initialized. The reason for this could have been the 
Sigma 5 programs, the transmission line, or the protocol 
between the computers. Because of this, the data had to be 
played back again. 

(4) Max/Min . These programs were used to keep a running record of 
the maximum and minimum values of pre-specif led measurements. 
When using these programs, the telemetry processor of the 
Sigma 5 computer would fail, resulting in the degradation of 
data. 

(5) Convert Coefficients . The raw PCM counts were converted to 
engineering values using coefficients stored in a table. On 
several occasions, this table changed without any reason. To 
correct this, the complete system had to be reloaded. This 
presented a severe problem. 

(6) Erroneous Data Values . On a few occasions, the telemetry 
processor failed and produced erroneous data values. The sys- 
tem had to be rebooted to correct this. 

All of the above problems, except limit checking, were corrected by 
Version 12 of the software, which was delivered by Univac on 12 September 1978. 


5-15 




2. Mission Operations Room/Sigma 5 Interface 

This interface functioned well. There were no significant hardware or 
software problems. 


3. Attitude Determination System/Sigma 5 Interface 

As mentioned earlier, a few problems were encountered. However, there 
were no serious impacts on operations. 


A. Orbit Determination System 

a. Predicts . It was the responsibility of ODS personnel to provide 
predicts for station view periods of the spacecraft to the MCT. On three 
occasions, the predicts were late by more than 2 days. This presented somewhat 
of a problem, especially immediately after orbit adjust maneuvers. On two 
different occasions, the revolution numbers of the spacecraft were off by more 
than one. To correct the latter problem, the predicts had to be regenerated. 


b. Range Tape . This set of data provided by ODS personnel to the MC T 
contained range information for the MIL, GWM, and MAD STDN sites. This data was 
needed to compute the spacecraft clock offset and drift. There were various 
problems encountered. On many occasions, the tape was defective and had to be 
regenerated. This usually required about 2 days and further aggravated the 
problem of computing clock offsets on rime. 


5. Command Management System 

The performance of the CMS supporting personnel for Seasat was outstanding. 
The MSOE memory loads were produced well in advance. There were few occasions 
when the transmission line between CMS and the POCC was not functional. The 
MSOE was hand-carried to the POCC. This procedure had no adverse impact on the 
operations . 


6. Ground Stations 

a. Tape Recorder Dumps . On 8 August 1978, because of timing problems 
in building up store and forward tapes, the MCT decided not to dump the tape 
recorders over ACN, MAD, and QUI . However, on 8 September 1978, the previous 
decision had been modified. The tape recorders could then be dumped over these 
sites, and the analog tapes could be shipped to MIL for transmission to the IPD 
at GSFC. From GDS , the shipping could be accomplished overnight, but times from 
the other sites were more variable and longer. Consequently, it was less 
desirable to dump tape recorders over the other sites. The priority established, 
in decreasing precedence, was ULA, MIL, MAD, and GDS. 
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b. STPN Scheduling . The STDN scheduling procedures established at GSFC 
worked satisfactorily. During the early part of this phase, the unavailability 
of STDN sites (CDS and MAD) presented a problem. These two STDN sites were used 
extensively by Skylab. MAD was one of the sites where tape recorder dumps were 
desirable, while GDS was one of two sites used for SAR data processing. As the 
-chedule was received by MCT at approximately 1930 GMT for the next day, and the 
ommand load tor the same day was already fabricated at that time, a few SAR 
aas commands in the load had to be no-ops because of the inability to schedule 
GDS. Similarly, if MAD was required for tape recorder dumps and was not avail- 
able, the dumps were scheduled over less desirable sites. 


e. Spacecraft Command Encoder Problems . SCEs at the STDN sites were 
used to uplink commands to the spacecraft. The command uplinking process 
involved a series of communication messages between the POCC computer and the 
SCEs. The characteristics of these communication messages were different for 
non-critical commands, critical commands, and memory loads. If this series of 
communication messages was not completed in its entirety on time, commands 
could not be uplinked to the spacecraft. The most frequent problem at the POCC 
was the failure to receive messages from the SCEs. This was indicated by a 
"SCE TIMED OUT" printout, meaning that the expected communication message from 
the SCE was not received by the POCC computer. The problem could be in either 
the SCE itself or in the NASCOM line from the STDN to the POCC. In the former 
case, the solution was to re- initialize the SCE. In the latter case, another 
attempt to uplink the commands had to be made. If the attempt was unsuccessful, 
a line check would be required. In any case, the uplinked commands would be 
delayed frem the intended uplink time. This was a problem for SAR turn-on 
and starting the tape recorder readout. This problem was not investigated by 
the Seasat Project. 

7. TELOPS/IPD 

TELOPS/IPD had six major interfaces in the Seasat configuration that were 
used either as an Input or output interface. In this paragraph, only POCC- 
related input and output interfaces will be discussed. There were one hard 
interface (voice line) and three soft interfaces where some data products were 
hand-delivered to either the POCC or TELOPS/IPD. The data delivered from 
TEI.0PS to the POCC were Seasat quick-look whole-orbit telemetry tapes. The 
POCC-supplied data products were daily copies of the Command Master Data File 
and the satellite time offset messages. 

The interface that worked best was that for the time offset messages. 

This message was delayed a few times where its delay impeded TELOPS/IPD data 
processing operations. The SFOP procedure stated that the SPAT would provide 
the data so that the message could be transmitted by 1600 GMT on the following 
day. During this phase only a limited number of time correlation passes were 
scheduled at the STDN sites. If for some reason one or two of these passes were 
lost or the data proved to be erroneous, it could delay that day's message until 
more time correlation passes were made, the data plotted, and a fit established. 
Also, for ease in data reduction, it proved better to have one person take all 
of the time offset data for that time period and perform a batch process for 
the day. It was this specialization in performing the task that also resulted 
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in some delays in processing non-real-time data. A lower priority on the 
processing of non-real-time data by real-time operations personnel caused a 
delay at times. All of these delays were minor, and, as it turned out, the 
facilities using this information to process Seasat data were also behind 
schedule with their own processing functions and the delays had no impact on 
their final output. As stated earlier, when this process was delayed because of 
problems with the ODS range tape, the output of time offset messages would fall 
behind by several days. When this occurred, there was an impact that caused some 
processing delays by TELOPS/IPD. 

The second interface was the voice interface between TELOPS and the POCC. 
This voice line was normally used only when real-time operations were being con- 
ducted with the STDN. This interface was activates by the Communications Manager 
when TELOPS/IPS was scheduled to receive playback from a tape recorder dump or 
a playback of an STDN store and forward tape. No notable real-time problems 
occurred with this voice line. The POCC personnel had expected to use this voice 
interface for non-real-time coordination of delivery of TELOPS quick-look tapes. 
In this respect, the interface failed. A second attempt to coordinate quick-look 
tapes was made using the standard telephones. This effort generally failed also 
because no knowledgeable single-point contact within TELOPS could consistently 
be established either by telephone or voice line. Ultimately, the Seasat Mission 
Support Manager provided this non-real-time coordination function. It was 
thought necessary to have a non-real-time POCC to TELOPS/IPS coordination effort. 
This interface requirement arose because of the impact of the late delivery of 
quick-look tapes from TELOPS to the POCC. This requirement diminished after 
TELOPS/IPD had solved their initial start-up problems encountered on Seasat data 
processing, and quick-look tapes were later provided within their specified 
delivery time of 4 to 6 h after capture of the data. 

The interface that resulted in the most problems was the quick-look tapes. 
Basically, the POCC required quick-look tapes for three reasons: (1) playback to 

the ADS; (2) playback to analyze the electrical power profile; and (3) playback 
to analyze the performance of a discrete sensor. Initially, the prime interest 
was in the areas of ADS and power evaluation. As these two subsystems and their 
performances became better understood under flight conditions, the requirements 
to analyze whole orbit data decreased. The evaluation of whole orbit data for 
sensor performance was on an "as required" basis. 

The MCT performed a total of 724 tape recorder dump cycles. Generally, 
each tape recorder contained approximately 230 min of data. This was equal to 
about two and one-third orbits of real-time data. Therefore, when a whole orbit 
of data was requested from TELOPS by the nature of the recorder cycles and 
TELOPS processing, over two orbits of playback data were received to be processed 
through the POCC Sigma 5 computer. Of the 724 playback cycles, four cycles were 
repeat playbacks from the satellite. These were normally the result of some 
ground system problem that caused a certain or probable loss of playback data. 

The total number of quick-look tapes requested, sometimes defined as whole 
orbit data, was 32. This was equal to approximately 4.44 percent of the total 
number of tape recorder cycles that were played back. It did not include the 
pre-planned quick-look requests through launch and approximately the first 


30 orbits. Nine of these dump cycles occurred during the first 2 weeks, which 
wss the Orbital Cruise Phase. During this phase* as noted in Section IV. the 
delay of the quick- look tapes severely handicapped the MCT and the SPAT* who 
required this data in a timely manner to evaluate the satellite and the 
attendant ADS and power system programs. 

Following this phase, and up to the point of the low voltage problem on 
orbit 891, 47 days and 10 quick- look requests elapsed, or an average of one 
request every 4.7 days. A review of the Seasat tape recorder management log 
illustrates that these requests were spaced relatively evenly throughout the 
overall time period. Delivery throughout this time period continued to lag 
1 or 2 days behind the request for quick-look data until the time of the under- 
voltage problem cited. Over a 2-day period (47 h) 7 of 13 tape recorder dumps 
were requested to be delivered to the POCC as quick- look tapes. On some of these 
orbits, two tapes (duplicate copies) were requested for individual GSFC experi- 
ment teams that had the capability to analyze the data on their own computer 
systems. Because of the size of the request at this time of the mission, the 
total process was somewhat slow. However, this event and the delivery of tapes 
from TELOPS did prove that the TEL0PS/1PD system could deliver data products 
across the interface within the prescribed time of 4 to 6 h after capture. 

Quick-look requests from the POCC from this time period to the time of 
spacecraft failure were again on a relatively evenly spaced basis. The TELOPS/ 
IPD concept of providing data for quick-look analysis was at the threshold of 
being consistently reliable within the desired time at the termination of the 
mission. In conclusion, the concept of individual POCC capture of data for real- 
time operations analysis should be strongly recommended for future missions. 


8. ULA Program 3 and 1.544-Mb/s Wideband Data Service 

A simplex 1.544-Mb/s wideband data service was provided from ULA with a 
simultaneous transmit capability to Fleet Numerical Oceanographic Center (FNOC) 
and to GSFC. This system was used to transmit the 800-kb/s playback telemetry 
data to FNOC and TELOPS/IPS at GSFC and the 25-kb/s real-time data to the 
Seasat POCC. 

ULA had two computer systems designated the 642B (Phase I) and the PDP-11 
(Phase II). These computers required Digital Data Processing System (DDPS) pro- 
gram 2 and DDPS program 3 software, respectively. To utilize 1.544-Mb/s data 
circuit capabilities, the DDPS program 3 had to he used. DDPS program 2 was the 
backup to DDPS program 3, and its use was intended in case of DDPS program 3 
failure only for real-time support. The 800-kb/s playback telemetry data were 
to be retained on station until the restoration of program 3 capabilities. 

During this phase of the mission, it was discovered that the dump data 
transmitted from ULA to TELOPS using DDPS program 3 contained timing problems. 

An extensive series of data flow tests were conducted between ULA and TELOPS to 
analyze this problem. The participation of the spacecraft operations team in 
these tests was not required. The timing problem revealed by these data flow 
tests were attributed primarily to the time code translator at ULA. Before the 
installation of this unit, it was checked at GSFC. However, one of the output 
cables was not terminated properly at the site. This cable was subsequently 
replaced, resolving all problems by 1 October 1978. 
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SECTION VI 


ORBIT MANEUVERS 


A. INTRODUCTION 

The Seasat spacecraft was launched at 01:12:44 GMT on 27 June 1978 from thi 
Western Test Range at Vandenberg Air Force Base, California. The launch and 
orbit injection were near-nominal, but post-launch attitude control anomalies anc 
the resultant hydrazine usage caused the pre-launch maneuver plans to be modified 
Following the development of a workaround for the attitude anomalies, five maneu- 
vers were executed. The following paragraphs summarize pre-launch maneuver plans 
launch results, post-launch plans, mission operations activities, and maneuver 
evaluations. 


B. PRE-LAUNCH MANEUVER PLANS 

The pre- launch maneuver strategy was to correct the achieved launch orbit 
within 30 days after injection. These corrections had the following objectives: 

(1) Achieve proper instrument operating altitudes. 

(2) Synchronize ground traces to match the pre-launch-generated ascending 
nodes (Earth-fixed) and dates. 

(3) Minimize altitude variations in the Northern Hemisphere. 

(4) Provide a 3-day, near-repeating ground trace for calibration 
activities. 

(5) Maintain the above properties against drag effects through periodic 
maneuvers. 

(6) Provide an exact 3-day repeat ground trace in early September for 
Bermuda laser experiments. 

Maneuvers were planned to correct semi-major axis (a), eccentricity (e), 
and argument of perigee (w). Corrections to ascending node locations (ft) were 
made by adjusting the semi-major axis, which affects the nodal precession rate 
(ft). Therefore, node control was performed by in-plane maneuvers rather than by 
expensive out-of-plane maneuvers. 

Parameters of the nominal launch orbit are listed in Table 6-1. The selec- 
tion of these values is discussed in detail in Reference 6-1. The values of 
semi-major axis and inclination determine the orbit precession rate and, coupled 
with the Earth spin rate, determine the Earth-fixed ground trace pattern. Fig- 
ure 6-1 shows how the ground trace pattern builds up over a typical equator seg- 
ment. The plot shows the Earth-fixed longitudes of ascending nodes plotted 
against time. The solid lines connect node locations that differ in time by 
3 days. The nominal orbit produces a 3-day near-repeating pattern that drifts 
18.5 km (10 nm) east every 43 revolutions (3 days). After 5 months, the 
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Table 6-1. Nominal Launch Orbit 


Parameters 

Valuee 

Semi-major axis, km 

7168.3 (3863.7 nm) 

Eccentricity 

0.0008 

Inclination, deg 

108.0 

Argument of perigee, deg 

90.0 

Time of perigee, 
nominal launch date 

00:46:00 GMT, 18 May 

Ascending node, deg 

298 


complete equator has been crossed every 18.5 km. setting up a uniform Instrument 
sampling grid. 

The nominal values of e and u were chosen to minimize altitude variations 
by providing a circular orbit and essentially no precession of perlapsis. As 
shown in Figure 6-2, the motion of c and u moves counterclockwise on the closed 
contours at the apsidal period (about 120 days). It can be seen that if 
c < 0.002 and o> ^ 90 deg, perigee precession is restricted to a small range of 
values. Near the "frozen" point, the motion will be essentially constant and, 
therefore, maintain the spacecraft altitude constant over any given point on 
Earth. This phenomenon is due to balancing the precession influence of the 
second zonal harmonic with the odd zonals by achieving a very small eccentricity. 
Details and equations to support these characteristics are given in References 
6-2 through 6-4. 

Nominal ground trace spacing is achieved once the nominal semi-major axis 
is achieved. However, launch date slips from 18 May, or an anominal launch 
performance causes the post-launch Earth-fixed ascending nodes to differ from 
the pre-launch nominal set (published in Reference 6-5). The nodal positions 
and times in Reference 6-5 were distributed before the initial planned launch 
date (18 May) to permit the instrument experiment teams to plan post-launch 
surface truth activities and to coordinate with other oceanographic activities. 
Therefore, it was planned to maneuver the spacecraft so that the actual nodes 
would agree with the published values. In other words, the effects of launch 
slips and launch trajectory errors on nodal positions would be compensated for 
with maneuvers. The nodal crossings were to be synchronized with nominal values 
by varying the semi-major axis so that the accumulated nodal errors would be 
offset within 30 days after launch. 

Reference 6-6 provides the maneuver strategy details and optimization 
techniques for correcting launch errors in a, e, and u> at the same time as node 
synchronization. Once node synchronization and launch error corrections were 
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completed, the Bermuda Island overflight would have occurred in early September, 

A small maneuver (approximately 700 ra (2296 ft) In semi-major axis) would then 
be required to modify the orbit from the near 3-day repeat (nominal orbit) to an 
exact 3-day repeat over Bermuda Island. The equations for computing the AV mag- 
nitude and location as a function of required changes to orbit parameters Aa, Ae. 
and Au are derived In Reference 6-2 and listed in Table 6-2. 

During this orbit sequence, maneuvers to compensate for drag were to be 
performed as needed. Drag caused the orbit to decay and the ground trace pattern 
to drift more easterly. Maneuvers were scheduled to return the semi-major axis, 
and e and u, if required, to their original values. As maneuver responsibilities 
were shared between operations teams at JPL and GSFC, a planning cycle and formal 
Maneuver Operations Planning Team (MOPT) were organized. 


C. launch RESULTS 

The powered flight trajectory produced an injection orbit that was within 
specifications, although somewhat off the nominal values (Table 6-3). Some of 
the nominal values in Table 6-3 differ slightly from those of Table 6-1, 
apparently due to round-off and precision requirements in LMSC ascent simula- 
tions. Figure 3-2 shows Lockheed Monte Carlo-modeled distributions for the 
orbit parameters of interest. The AV required to correct the launch orbit was 
6.3 m/s compared to a nominal value of 4.4 m/s and a 99 percent probability 
level of 11 m/s. 

The coverage from the launch orbit is plotted in a dot diagram in Fig- 
ure 6-3. The dots show the Earth-fixed longitudes of ascending nodes plotted 
against time. The abscissa shows a typical equator segment, with the plotted 
pattern being repeated around the equator. A long-term 17-day repeat pattern 
with a .arger miss distance of 160 km (86 nm) is evident. The curvature in the 
17-day near-repeat pattern is due to drag effects on the semi-major axis that 
changed the nodal precession rate, which in turn affected coverage. Note that 
the 17-day pattern does not exactly repeat itself, but misses to the west for a 
while and then misses to the east. Either an east or west stepping pattern 
could be maintained with maneuvers. 

The 17-day pattern was advantageous in that it provided an almost 18-km 
(9.7 nm) spacing between adjacent ground traces. This corresponded to the 
altimeter long-term mapping requirement. A disadvantage of the launch orbit was 
that the 3-day pattern had a miss distance about 50 percent larger than the SAR 
swath width of 100 km (54 nm) . Therefore, the SAR and instruments with smaller 
coverage swaths did not have contiguous coverage for long periods of time. As 
both the Baseline and Cambridge orbits (Table 6-4) were configured to provide 
overlap coverage consistent with the instrument swaths, it was decided not to 
stay in the launch orbit but to comply with the initial maneuver objectives. 


D. MISSION OPERATIONS ACTIVITIES 

Twenty-six hours after launch, vehicle attitude control was transferred 
from the Reaction Control System (RCS), which used gyros and hydrazine gas, to 
the Orbital Attitude Control System (0ACS), which used horizon sensors and 
momentum wheels. Subsequent to the transfer, large transients were observed 
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Table 6-3. Achieved Injection Conditions 


Parameter 

Value 

Cumulative 
Probability 
Level, (%) 

Pre-Launch 

Specification 

Semi-major axis, km 

Mean 

7170.271 

50.45 

7150 to 7186 


Nominal 

7168.7 

30.93 



Actual 

7162.770 

0.89 


Eccentricity 

Mean 

0.001560 

54.84 

0.0 to 0.0052 


Nominal 

0.0008 

15.75 



Actual 

0.000667 

9.99 


Inclination, deg 

Mean 

108.09 

51.80 

107.5 to 108.5 


Nominal 

108.00 

20.10 



Actual 

108.023 

27.07 


Argument of perigee. 

Mean 

71.7 

61.82 

0 to 360 

deg 

Nominal 

90.4 

87.68 



Actual 

254.0 

99.86 



in both the roll and yaw attitudes. The spacecraft was returned to RCS control, 
and all pre-launch maneuver plans were cancelled pending resolution of the 
problem. 

Data analysis showed that the attitude disturbances occurred at specific 
locations in each revolution, suggesting that the anomalies were attributable 
to sunlight entering the field-of-view of one or bath horizon sensors. By 
late July, it was determined that orbit precession had sufficiently changed the 
sun geometry, and the spacecraft was returned to OACS control using only the 
right horizon sensor head. No additional disturbances were observed, and per- 
mission was given to begin the maneuver series on 15 August. 

Because of the delay caused by the attitude anomaly, the original maneuver 
plan was revised. The Baseline orbit was established with the frozen orbit 
condition by 26 August. Node control for the Bermuda orbit was to be such that 
a descending pass occurred directly over Bermuda Island on 8 September. The 
spacecraft was then to be maneuvered into an exact 3-day repeat orbit that 
passed over Bermuda every third day. This orbit was to be used for approxi- 
mately 1 month, when a Cambridge orbit would be established to provide a gradu- 
ally shifting coverage pattern. The orbit definitions are given in Table 6-4. 

The revised schedule is presented in Table 6-5. Six maneuvers were 
scheduled to meet experiment objectives. All pre-launch defined maneuver inter- 
faces were exercised as planned. The MOPT was convened twice during each maneu- 
ver cycle, and maneuver plans and results were widely distributed. 
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Figure 6-3. Seasat Launch Orbit Ascending Node Pattern 






Table 6-4. Orbit Definitions 


Baseline orbit 


Cambridge orbit 


Exact 3-day repeat 
orbit 


Launch orbit 


17-day near-repeat 
orbit 


Node control 
condition 


Frozen orbit 
condition 


A 3-day near-repeat orbit which moves 18. 5 km (10 nm) 
to the east every 3 days. Has advantages of multiple 
coverage of fixed locations and good orbit stability 
with respect to drag. 

A 25-day near-repeat orbit which moves 18.5 km to the 
east every 25 days. Has advantage of fast global 
coverage and optimum SAR swathing. 

A 3-day exact-repeat orbit which provides near-zenith 
descending node passes over BDA every 3 days. Has 
advantages for ALT calibration. 

The orbit actually achieved by the spacecraft on 
June 27. This orbit has identifiable 3-day and 
17-day cycle components (see Figure 6-3). The orbit 
spacing changes with time due to drag (i.e., no 
maintenance maneuvers) . 

17-day near- repeat orbit which is close to the launch 
orbit. Moves 18.5 km to the west every 17 days (other 
spacings are possible) . 

The condition which exists when the node control 
maneuver synchronizes the ascending node longitudes 
and times to the pre-flight plan. 

The condition which exists when the orbit adjust 
maneuver achieves orbital elements which freeze peri- 
gee at the maximum north latitude excursion, thereby 
minimizing altitude and altitude rate variations in 
northern hemisphere (desirable for the SAR). 


The first orbit adjust thruster (OAT) firing occurred at 07:41 UTC on 
15 August. This maneuver wan to calibrate the -AV thruster. Subsequent maneu- 
vers were then performed to change the nodal precession rate, calibrate the +AV 
thruster, synchronize with nominal ascending node locations, and achieve the 
3-day repeating orbit over Bermuda. Each maneuver after the first calibration 
burn was modified slightly to adjust for errors in the previous burn and to 
correct for drag prediction errors. The error from maneuver 4 caused the 
Bermuda overflight to slip from 8 September to 10 September. This was acceptable 
to the altimeter team, and the trim maneuver scheduled for 1 September was 
cancelled. 
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Table 6-5. Maneuver Timeline 


Date 


15 August 


18 August 


23 August 


26 August 


1 September 


8 September 


Maneuver 


Description 


Calibration No. 1 Calibrate -AV thruster 

60-s burn. 

Aa st -1 km 


Orbit adjust No. I Orbit adjust No. 1 changed nodal preces 

slon rate. 

Post-maneuver orbit: 


a * 7160.1 
e as 0.00143 
u; ae 146.27 
i - 108.023 
ft =* 87.7 


Calibration No. 2 Calibrate +AV thruster 

60-s burn. 

Aa * +1 km 


Orbit adjust No. 2 Orbit adjust No. 2 achieved the ncninal pre- 
flight nodes. The orbit was a baselire 
ground trace with about 11-km spacing (east) 
and a near-frozen orbit: 

Pos t-maneuver orbit 

a as 7168.6 
e — 0.0008 
u) as 95 
i - 108.023 
ft =* 104.3 


T rim No. 1 Trim No. 1 was to correct any execution 

error resulting from OA No. 2. This maneu- 
ver would ensure that the Bermuda overflight 
would occur on 10 Sep ±1 day. 


Orbit change No. 1 Orbit change No. 1 achieved the 3-day exact- 

repeat which was a descending leg over 
Bermuda Island. 

Post-maneuver orbit: 

a as 7169.0 
e * 0.0008 
to — 90.0 
i - 108.023 
ft a: 126.7 


E 


MANEUVER EVALUATIONS 


The Seasat maneuvers were all executed successfully with near-perfect 
tesults. All maneuver objectives were attained, and no abnormalities occurred. 

The performance results for the maneuvers are summarized in Table 6-6. 

Figure 6-4 shows the variation of e and w from launcn until 26 August 
1978. The normal precession of e a id io prior to maneuvers is evident, and the 
maneuvering to the "frozen" (zero precession) point is illustrated. Since 
10 September, when the frozen orbit was established, the values of e and u, 
while not entirely constant, shew very small amounts of motion (Figure 6-5). 

The small remaining variation in c and u is due to scatter in OD solutions plus 
the effects of high-order harmonics, solar radiation pressure, atmospheric drag, 
sun and moon gravity, etc. Figure 6-5 also shows the GSFC predicted motion of e 
and M for the next year with constant values of drag and solar radiation pressure. 

It can be seen that the values would vary between 0.00075 Se £ 0.00084 and 
86.5 deg < u> <94.5 deg in a slow spiral during the next year. Perturbation 
analyses at JPL and GSFC have shown the main cause of the non-zero precession to 
be solar radiation pressure and drag. These small variations are well within 
the design goals needed to keep the altitude variation essentially constant over 
any latitude. Also, corrections to c and m would have been made when maneuvers 
were made to correct semi-major axis decay due to drag (about every 2 months), 
or when the orbit ground trace pattern was changed. The next maneuver on 
26 October would have been to go to the Cambridge ground trace pattern. The 
values of e and u> would have been targeted to 0.0008 and 90 deg, respectively. 

The semi-major axis history during the maneuver period is plotted in Fig- 
ure 6-6, which showr* both the actual and nominal values. The OD precision is 
±30 m (98 ft) or better in semi-major axis. The largest execution error 
(absolute value) was 57 m (187 ft) from maneuver 4 (Table 6-6). The effect of 
drag on semi-major axis can be seen in Figure 6-7. Although the scatter in OD 
is evident, a clear decay of about 3 m/day is predominant, especially after 
18 September. Figure 6-8 shows a plot of ,olar activity since launch. Atmos- 
pheric drag generally followed the solar flux activity. JPL and GSFC orbit 
prediction programs used an average value of flux of 150 for most periods, and 
generally had good agreement with actual results. 

Achieving the exact 3-day repeat orbit over Bermuda on a specific date was 
the most challenging requirement. The nominal pre-launch Bermuda overflight 
was 2 September, After launch, if no maneuvers were made, passes over Bermuda 
would occur about every 17 days. However, because of the large difference in 
semi-major axis between the launch orbit and the 3-day repeat orbit, a single 
corrective maneuver would not be advisable because of the size of likely exe- 
cution errors. Also, the overflight dates without maneuvers were 31 August and 
16 September. Because of the previously discussed attitude problems, the 
earliest first maneuver date was 15 August. The maneuver sequence of Table 6-5 
was designed to produce a Bermuda overflight on 8 September. The slip from 
2 September was necessary because of the late maneuver start date and the number 
of maneuvers required. Figure 6-9 shows the ground trace position relative to 
Bermuda Island during the maneuver period. The first two maneuvers changed 
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Table 6-6. Maneuver Performance 
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Figure 6-7. Semi-Major Axis Decay in Exact Repeat Orbit 




FAILURE 



Figure 6-8. Solar Activity During Seasat Mission 
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Figure 6-9. Bermuda Miss Distance and Closure Rate 




ao that the nominal pre-launch nodes were matched on 26 Augusts The second two 
maneuvers changed ^ to match the nominal baseline orbit value (i • e . , cause a 
3-day near-repeat ground trace). After 26 August* the ground trace was about 
42 km (23 nm) west of Bermuda and every 3 days the ground trace precessed 9 km 
(5 nm) closer. The ascending nodes for a Bermuda overflight were achieved on 
10 September at 01:10:36 GMT. A 28-s burn was centered around this time to 
change Cl so that the 3-day drift rate was zeroed out (i.e.» an exact 3-day repeat 
was achieved). 

Actually* a slight westward drift of 0.7 km (0.38 nm) every 3 days was 
intentionally introduced to oppose the effects of drag and* therefore* increased 
the time during which the Bermuda overflights would stay within tolerance. This 
maneuver was intentionally small so that thrust or timing errors would not cause 
a large miss distance or Introduce large drift rates. This maneuver was 
essentially perfect. The first Bermuda overflight was 100 m (328 ft) west of 
the Bermuda laser site. Figure 6-10 shows the predicted and actual miss dis- 
tances relative to Bermuda (i.e.* at 30-deg latitude) from 10 September to 
30 October. The maximum west miss was 3.7 km (2 nm). The ground trace stayed 
within 5 km (2.7 nm) of the laser site for 45 dayB. The ground trace actually 
drifted farther west than anticipated. This occurred because the semi-major axis 
did not decay as much as predicted from 10 to 20 September (Figure 6-7) even 
though the solar flux predictions were very close to actual values (Figure 6-8). 

The hydrazine usage is shown in Figure 6-11. The ascent and early orbit 
usages were much higher than nominal because of the attitude anomaly and the 
delay in going to the wheel attitude control system. Table 6-7 lists the pre- 
launch and actual AV budget. It can be seen from Table 6-7 ';hat nearly one-half 
of the total hydrazine was uncommitted and could have been used for additional 
orbit changes or attitude maneuvers. To illustrate the capabilities of the 
remaining hydrazine supply, enough fuel remained aboard the spacecraft to com- 
plete all planned maneuvers and do maintenance trims to compensate for drag for 
over 40 years. 

As the power failure precluded any additional maneuvers, the spacecraft 
will remain in a 3-day near-repeat orbit. The miss distance as of 1 November 1978 
was 3 km (1.6 nm) west, which would grow to 7 km (3.8 nm) west every 3 days by 
1 January 1979. The spacecraft will remain in a 3-day near-repeat orbit for 
years, although the 3-day drift rate constantly increases. It is possible that 
the spacecraft could be useful in future geodesy applications because it is large, 
has a laser reflector ring, and is in an easily predicted orbit. Despite the 
early end to experiment data collection, all maneuver objectives were demon- 
strated, except for long-term maintenance. The power failure also prevented 
long-term data collection from a uniform global coverage pattern. 
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Figure 6-10. Bermuda Miss Distance 
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Tabic 6*7. Pre-Launch and Actual AV Hydrazine Allotment 



Pre-Launch 

Post-Launch 


V + 3o, 

Nominal 

Actual, Planned* 


m/s 

(y).»/a 

m/s m/s 

Ascent attitude control 

4.16 

2.82 

7.28 

Orbit adjust 
(lncl. node control) 

25.78 

4.40 

7.27 

Baseline to exact 3-day repeat 

0.52 

0.48 

0.45 — 

Exact 3-day to Cambridge 

3.75 

3.62 

3.62 

Cambridge to baseline 

3.06 

3.01 

3.01 

Maintenance trims (3 yr) 

7.18 

1.49 

1.39 

Thruster resolution (0.5 s) 

0.31 

0 

— 

Total usage 

/ 38.0 \ 
(y + 3o ) 
\o - 1550 i / 

15.8 

23.02 

Total capability 

47.2 

47.2 

47.51 

Margin 

9.2 

31.4 

24.5 
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SECTION VII 


satellite failure 


A. INTRODUCTION 

Seasat ceased downlink transmission following an electrical power system 
failure on 10 October 1978. Subsequent attempts to re-establish communications 
with the satellite were unsuccessful, and flight operations were discontinued on 
10 November 1978. The contents of this section summarize Project Operations Sys- 
tem (POS) activities from first observation of the malfunction until termination 
of mission operations. 


B. MISSION OPERATIONS ACTIVITIES 

The first indication of a satellite malfunction was observed during a 
rev 1503 contact by the Santiago, Chile (AGO) tracking station. At the AGO 
acquisition time of 03:29 UTC, satellite engineering data indicated a number of 
out-of-tolerance conditions for electrical power and thermal systems measurements. 
On observing these data, the on-duty mission controller and lead spacecraft 
analyst agreed on a course of action that included validation of the ground data 
system, investigation of a potential Telemetry/Sen3or Interface Unit (TSU) failure, 
and analysis of the power system measurements to identify a potential short 
circuit. 

The supposition that the problem could be attributable to ground processing 
was based on pre-launch and early mission experience in which frequent instances 
of erroneous data display were encountered. Data reliability was also questioned 
in view of a TSU multiplexer failure potential identified during vehicle 
pre-flight testing. Finally, detailed analysis of the power system measurements 
was considered necessary because the available data were indicative of a shorted 
load, but no abnormal satellite subsystem loads could be identified. 


1. Failure Observation 

A detailed chronology of the events and activities that followed discovery 
of the power anomaly is given in Table 7-1. Analyses were not completed before 
the loss of signal at AGO at 03:42 UTC, and additional priority monitoring was 
requested for 03:59 UTC at the Orroral, Australia (ORR) tracking station. The 
majority of the ORR data were not observed in real time because of data system 
restarts and, following the loss of signal at 04:08 UTC, the station was requested 
to replay the satellite data from analog station tapes. By the completion of the 
ORR playback at 04:20 UTC, both ground system and TSU failure modes had been 
discounted, and the investigation centered on isolation of a satellite short 
circuit. 

At the next scheduled contact at 04:44, the Shoe Cove, Newfoundland (SNF) 
station reported no acquisition of the satellite downlink. Following a second 
report of no acquisition at 04:52 from the Merritt Island, Florida (MIL) station, 
a spacecraft emergency condition was declared, and contingency command sequences 
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Table 7-1. Failure Event Chronology, 10 October 1978 (Day 283) 


Time (UTC) 


Event 


03:29:43 


03:31:37 

to 

03:32:01 

03:33:08 

to 

03:33:40 

03:40:00 

03:42:53 

03:43:00 

to 

03:59:00 


AGO acquisition 

Unregulated bus \oltage 24.03 V 

Battery 1 current 51.50 A 

Battery 2 current 51.80 A 

Structure current 0.199 A 

Vehicle and sensor subsystem leads normal 
Discussion of data condition and course of action 

1. Potential ground processing problems 

2. Potential TSU failure 

3. Potential vehicle short circuit 
Restart of control center computer 

Restart of statl decom and data processing computers 

Request for additional tracking coverage from 0RR 
AGO loss of signal 
Status >f analysis 

1. Control center engineering unit conversion suspect 

2. TSU failure potential unresolved 

Vehicle short circuit could not be attributed to a partic- 
ular system failure 


3 . 


Table 7-1. Failure Event Chronology, 10 October 1978 
(Day 283) (Continuation 1) 


Time, UTC 


Event 


03:59:09 


04:03:08 

to 

04:06:58 

04:08:28 

04:09:00 

to 

04:20:00 

04:20:00 

to 

04:44:00 


04:44:00 

04:52:00 

04:55:00 

05:01:00 

to 

05:04:00 


ORR acquisition 

Unregulated bus voltage 21.00 V 

Battery 1 current 43.10 A 

3attery 2 current 41.10 A 

Structure current 10.00 A 

Vehicle and sensor subsystem loads normal 

Swap out control center disk containing engineering unit con- 
version tables (unsuccessful) 

ORR loss of signal 

ORR playback from analog tape 

Status of analysis 

1. Ground processing valid 

2. TSU failure not indicated 

3. Vehicle short circuit indicated, but not localized; con- 
tin' -ncv commands planned for MIL. 

SNF (receive-only site) reports no acquisition 

MIL reports no acquisition 

Spacecraft emergency condition declared 

Contingency commands to remove sensor loads transmitted from MIL 
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Table 7-1. 


Failure Event Chronology , 10 October 1978 
(Day 283) (Continuation 2) 


Time, UTC 


Event 


05:09:00 

05:10:00 

to 

05:13:00 

06:32:00 

06:35:00 

to 

06:38:00 

08:11:00 


08:15:00 

to 

08:18:00 


QUI reports no acquisition 

Contingency coimnands to remove sensor loads transmitted from 
QUI 

Mil reports no acquisition 

Contingency commands to remove sensor loads transmitted from 
MIL 

CDS reports no acquisition; both 9- and 26-m antennas searching 
for downlink 

Contingency commands for downlink recovery transmitted from GDS 


designed to remove the sensor loads from the satellite power bus were transmitted. 
Spacecraft controllers then continued to transmit these commands, as well as a 
downlink recovery sequence, at each potential contact. 

The spacecraft emergency was declared at 04:55, and project personnel at 
JPL, GSFC , and LMSC were notified. Under the direction of the Mission Manager, 
an anomaly investigation team was formed, and communication circuits were 
obtained for team coordination. The organization, activities, and findings of 
the anomaly team are documented in Volume II of this report. 


2. Data Retrieval and Distribution 

The role of the POS during the anomaly investigation included the retrieval 
and distribution of pertinent satellite data as Jisted in Table 7-2. 


3. Recovery Strategies* 

The implementation of recovery strategies recommended by the anomaly team 
is given in Table 7-3. 


Table 7-2. Failure Data Distribution 


Site 

Orbit 

Data Type 

Data Time 

Via 

Format 

To 1C Heads 

MAD 

1501 

PB 

282/1803-2153 

IPD 

PMDF 

JPL/PDPS 

ORR 

1502 

PB 

282/2148- 

IPD 

Quicklook 

GSFC/POCC 




283/0137 

IPD 

PMDF 

JPL/PDPS 

UKO 

1502 

RT 

283/0122-0136 

WNK 

Analog 

ETC 





ETC 

NASC0M 

GSFC/POCC 





ETC 

NASCOM 

IPD 





IPD 

PMDF 

JPL/PDPS 

ORR 

150^ 

RT 

283/0217-0231 

IPD 

PMDF 

JPL/PDPS 

UKO 

1503 

RT 

283/0300-0313 

WNK-1 

Analog 

ETC 





ETC 

NASCOM 

GSFC/POCC 





ETC 

NASCOM 

IPD 





IPD 

PMDF 

JPL/PDPS 

AGO 

1503 

RT 

283/0329-0342 

GSFC/ 

History 

JPL/PDPS 





P0CC 

Tape 






IPD 

PMDF 

JPL/PDPS 

ORR 

1503 

RT 

283/0359-0408 

IPD 

PMDF 

JPL/PDPS 

Note : 

UKO 1502 

and 1503 dat 

' transmitted from Winkfield, UK via Data 


Transmis 

sion System 

JTS) to GSFC Multi Satellite Operations Control 


Center I 

(MSOCC I) 






4. Possible Contacts 

An intense tracking schedule was maintained through 21 October 1978, when 
attempts to reacquire the downlink were reduced :o periods during which the 
satellite was in sunlight. During intensive tracking, a number of weak signals 
were reported at the Seasat downlink frequency; however, these were subsequently 
discovered to be other spacecraft transmitting at the same frequency or station 
internally generated signals (Table 7-4). 

On 10 November 1978, following 31 days of attempts to re-establish satel- 
lite communications, flight operations were discontinued, and project activities 
were directed to detailed failure analysis and science data evaluation. 
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Table 7-3. Recovery Sequences 


Ssq. 

Downlink 

JJp 1 \k 

CcNMnds 

First Use 

Results 

1 

Freq: 2287.5 MU 

Tunc: +5/-10 MU 

Nona 

Nona 

MIL 1512 

Net 

2 

Standard procadura 

Freq: 2106.4 rfHz + Doppler 

Sweep: ?45 kHz/ 20 a (auto) 

Sensors off. 
Downlink recovery 

CDS 1513 

Nig 

3 

Standard procedure 

10* rice 

Freq: 2106.32 MHz 

Sweep: t25 kHz/20 a (auto) 

6 Hweepe: command 

Sensors off. 
Downlink recovery 

HAW 1514 

N«g 



10* set 

Freq: 2106.4 MHz 

Sweep: ±25 kHz/20 a (auto) 

1 sweep: command 

Sensors off. 
Downlink recovery 



4 

Standard procedure 

AOS: 3 min 

Freq: 2106.373 MHz + Doppler 

Sweep; ±45 kHz/20 a (auto) 

3 sweeps: command 

Sensors off. 
Downlink recovery 

HAW 1515 

Neg 



LOS: 3 min 

Freq: 2106.373 MHz + Doppler 

Sweep: ±45 kHz/20 a (auto) 

1 sweep: command 

Sensors of f . 
Downlink recovery 



5 

Standard procedure 

Freq; ”.106. 373 MHz 
Sweep: ± Doppler, +50 kHz/ 

20 s (manual) 

1 sweep: command 

Sensors off. 
Downlink recovery 

CDS 1535 

Neg 

b 

AOS 

Freq: 2287.495 MHz 

-AOS Doppler 
Tune: ±50 kHz 

(manual ) 

None 

None 

UUV 1541 

Neg 

7 

1-way sequence 
Freq : 2287.5 MHz 

Tune: ±300 kHz 

2-way sequence 

Freq: 2101.373 MHz + Doppler 

Sweep: ±45 kHz/20 s (auto) 

3 sweeps: command 

0072,0040* 0245, 
0266, 0030, 0042. 
0064, 0106, 0200, 
0231, 0300 

CWM 1544 

Neg 




Contingency 
sequence 1 






Contingency 
sequence 2 
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Table 7-4. Possible Seasat Contacts 


Orbit 

Site 

Time* UTC 

Description 

Data 

Recorded 

Probable Source 

1306 

UKO 

283/08(10 

Trane t con tec t 

No 

GE0S-3 

1507 

UKO 

283/09:47-09:51 

Trenet contact 

No 

CEOS-3 

1508 

UKO 

283/11:12:43-11:12:32 

283/11:13:20-11:13:24 

Two burata (7 a and 4 a) at 
2282.5 MHz. No receiver lock. 

No 

Downlink frequency 
not Seasat 

1509 

ULA 

283/13:13:00 

Momentary signal at 2280.0 MHz 

No 

Site internal signal 

1510 

BDA 

283/14:32-14:38 

Approximately 6-min weak sig- 
nal at 2287.5 MHz. No 
receiver lock. 

No 

Landsat-3 

1510 

MIL. 

283/14:37:20-14:37:25 

5-s weak signal at 2287.5 MHz. 
No receiver lock. 

No 

Landsat-3 

1511 

SNF 

283/16:18 

Momentary signal at 2287.5 MHz. 
Decom output SAR quicklook data. 
SAR data erroneous. 

Yes 

Data not Seasat 

1518 

UKO 

284/04:20:00 

Momentary signal at 2280.0 MHz. 
“o receiver lock. 

No 

Downlink frequency 
not Seasat 

1518 

SNF 

284/04:28:00 

Momentary signal at 2287.5 MHz. 
Decom output SAR quicklook 
data. SAR data erroneous. 

Yes 

Data not Seasat 

1524 

SNF 

284/14:04 

Momentary signal at 2287.5 MHz. 
No decom output. 

No 

Undetermined 

1538 

SNF 

285/13:36:00 

Momentary signal at 228/5 MHz. 
Oecom output SAR quicklook data. 
SAR data erroneous. 

Yes 

Data not Seasat 

1542 

ULA 

285/20:46 

Approximately 1-min weak signil 
at 2287.5 MHz. No 'o^eiver L'ck. 

No 

Landsat-3 

1551 

SNF 

286/11:33 

Momentary signal at 2287.5 MHi . 
Decom output SAR quick- look data. 
SAR data erroneous. 

Yes 

Data not Seasat 

1552 

SNF 

286/13:10 

Momentary signal at 2287.5 MHz. 

De :ora output SAR quick-look data. 
SAR data erroneous. 

Yes 

Data not Seasat 

1553 

SNF 

286/14:41 

Receiver lock on strong 

signal at 2287.5 MHz. No decom 

output. 

No 

Landsat-3 

1554 

MIL 

286/16/26:11-16:28:30 

Approximately 20-s signal at 
2287.1 MHz. 

No 

Site Internal signal 

1555 

CDS 

286/18:12-18:16 

4-min weak signal at 2287.5 MHz, 
No receiver lock. 

No 

Landsat-3 

1556 

ULA 

286/19:55-19:57 

2-min weak signal at 2287.4 MHz. 
No receiver lock. 

No 

Lanusat-3 

1557 

ULA 

286/21:33:40 

Momentary signal at 2287.5 MHz. 
No receiver lock. 

No 

Landsat-3 

1575 

SNF 

288/04:10 

No indication of signal, but 
decom output SAR quick-look data. 
SAR data erroneous. 

Yes 

Data not Seasat 


7-7 


Table 7-4. Possible Seasat Contacts (Continuation 1) 


Orbit 

Site 

Tim*, irrc 

Description 

Data 

Recorded 

Probable Source 

1580 

UKO 

288/12:08*12:09 

3-si^nal burets at 2287.5 KHz. 
No receiver lock. 

No 

Landsat-2 

1580 

SNF 

288/12:20:35 

Same as orbit number 1575. 



1582 

ETC 

288/15:29:10*15:38:30 

9-min weak signal at 2267.5 MHz 
Doppler rate not indicative of 
Seasat track. 

No 

Landsat-2 

1582 

SNF 

288/15:32 

Same as orbit number 1575 



1585 

ULA 

288/20:37:40-20:42:00 

4-min weak signal at 2287.5 MHz. 
Doppler rate not indicative of 
Seasat track. 

No 

Landsat-2 

1595 

UKO 

289/13:20-13:22 

Two momentary signal bursts at 
2287.5 MHz. No receiver lock. 

No 

Landsat-3 

1596 

ULA 

289/15:14-15:21 

8-min weak and intermittent sig- 
nal at 2287.5 MHz. No receiver 
lock. 

No 

Site internal signal 

1599 

ULA 

289/20:08-20:13 

Several signal bursts at 2287.5 
MHz. No receiver lock. 

No 

Landsat-3 

1622 

MAD 

291/10:41:00-10:43:40 

Over 2-min weak signal at 2267.5 
MHz. Doppler rate not indicative 
of Seasat track. 

No 

Landsat-2 

1623 

MAD 

291/12:23:20 

Momentary signal burst at 2287.5 
MHz. No receiver lock. 

No 

Landsat-2 

1627 

ULA 

291/19:14:00-19:15:30 

1 1 /2-min weak signal at 2287.5 
MHz. No receiver lock. 

No 

Landsat-2 

1662 

SNF 

294/06:19 

Same as orbit number 1575. 



1663 

SNF 

294/07:53 

Same as orbit number 1575. 



1665 

MAD 

294/10:45:50-10:58:10 

Over 2-min weak signal at 2287.5 
MHz. Doppler rate not indicative 
of Seasat track. 

N.i 

Landsat-2 

1690 

SNF 

295/05:18 

Same as orbit number 1575. 



1691 

SNF 

295/06:57 

Same as orbit number 1575. 



1704 

SNF 

297/04:51 

Same as orbit numter 1575. 



1718 

SNF 

298/04:21 

Same as orbit numbev 1575. 



1719 

SNF 

298/06:03 

Same as orbit number 1575. 



1720 

SNF 

298/07:41 

Same as orbit number 1575. 



1733 

SNF 

299/05:33 

Same as orbit number 1575. 



1734 

SNF 

299/07:11 

Same as orbit number 1575. 
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AAFE 

ACMO 

ACN 

ACS 

AD 

ADF 

ADL 

ADR 

ADS 

AE 

AFB 

AFIOS 

AFSCF 

AFSTC 

AFWTR 

AGC 

AGO 

ALT 

AM 

A/O 

AOS 

AOl 

APL 


ABBREVIATIONS AND ACRONYMS 

Advanced Application Flight Experiment 

Assistant Chief of Mission Operations 

STDN Station at Ascension Island, United Kingdom 

Attitude Control System 

Attitude Determination 

Algorithm Development Facility 

Analog Data Link 

Auxiliary Data Record 

Attitude Determination System 

Atmospheric Explorer 

Air Force Base 

Air Force Indian Ocean Station 

Air Force Satellite Control Facility 

A... Force Satellite Test Center 

Air Force Western Test Range 

Automatic Gain Control 

STDN Station at Santiago, Chile 

Radar Altimeter 

Amplitude Modulation 

Attitude/Orbit 

Acquisition of Signal 

Attitude Orbit Tape 

Applied Physics Laboratory, Johns Hopkins University 


ARIA 

ATT 

BDA 

BECO 

BED 

CCOM 

CCRS 

CCSM 

CCT 

CDR 

CLA 

CMD 

CMDF 

CMDR 

CMF 

CMO 

CMS 

CRP 

CRT 

CSTA 

CTU 

CTV 

CY 

DAF 

DAL 

DDPS 

DMT 


Advanced Range Instrumentation Aircraft 
Attitude 

STDN Station at Bermuda, United Kingdom 
Booster Engine Cutoff 
Block Error Decoder 

Control Center Operations Manager 
Canadian Center for Remote Sensing 
Control Center Systems Manager 
Computer Compatible Tape 
Critical Design Review 
Control Logic Assembly 
Command 

Command Master Data File 
Command Master Data Record 
Command Management Facility 
Chief of Mission Operations 
Command Management System 
Command Request Profile 
Cathode Ray Tube 

Computer Sciences Technicolor Associates 
Central Timing Unit 
Compatibility Test Van 
Calendar Year 

Definitive Attitude File 
Data Accountability Log 
Digital Data Processing System 
Data Management Team 
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DoC 

DoD 

DOY 

DREO 

DRS 

DSC 

DTS 

ESA 

ETR 

FMOC 

FNOC 

FSK 

FY 

GDS 

GDSE 

GE 

GIC 

GMT 

GOASEX 

GPS 

CRTS 

GSFC 

GWM 


Department of Commerce 
Department of Dafanaa 
Day of Yaar 

Dafanaa Raaaarch Establishment, Ottawa 
Data Records System 
Data Sat Controllar 
Data Transmission Systam 

European Space Agency 
Eastern Test Range 

Flight Maneuver Operations Center 

Fleet Numerical Oceanographic Center (U.S. Navy), Monterey, CA 
(formerly Fleet Numerical Weathe Central) 

Frequency-Shift Keyed 

Fiscal Year 

Ground Data System; 

STDN Station at Goldstone, CA 

Ground Data System Engineer 

General Electric 

Geocentric Inertial Coordinate 

Greenwich Mean Time (Zulu Time) 

Gulf of Alaska Seasat Experiment 

Global Positioning System 

Goddard Real-Time System 

Goddard Space Flight Center 

STDN station at Guam, Marianas Islands 


HAW 

HDD a 

HMRCC 

HSD 

HSDL 

HSK 

HVPS 

IBM 

ICD 

I DPS 

IF 

IP 

IPD 

IR 

IRV 

ISEE 

JASIN 

JPL 

KSC 

LMSC 

LOB 

LOS 

LOX 

LRT 


STDN Station at Kauai, HA 

High Density Digital Recorder 

High Mode Reaction Control Cluster 

High-Speed Data 

High-Speed Data Line 

High-Speed Keying 

High Voltage Power Supply 

International Business Machines 
Interlace Control Document 
Instrument Data Processing System 
In Le rmed i a t e Fr eq uenc y 
Input Processor 

Information Processing Division 
Infrared 

Interrange Vector 
International Sun- Earth Explorer 

Joint Air-Sea Interaction Experiment 

Jet Propulsion Laboratory (NASA), Pasadena, CA 

Kennedy Space Center (NASA), FL 

Lockheed Missiles and Space Company, Inc., Sunnyvale, CA 

Launch Operations Building 

Loss of Signal 

Liquid Oxygen 

Lov, -Rate ~tleraetry 
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LRTS 

LSWA 

LTWG 

MAD 

mo 

MCCC 

MCCO 

MCR 

MCT 

MDMT 

MDR 

MDS 

MFR 

MIL 

M&O 

MOA 

MOCF 

MOP 

MOPT 

MOR 

MOS 

MOSS 

MPS 

MPSS 

MPT 

MSA 

1ISC&AD 


Low-Rate Telemetry System 
Left Scan Wheel Assembly 
Launch Test Working Group 

STDN Station at Madrid, Spain 

Magnetic Control Assembly 

Mission Control and Computing Center 

Mission Control Center Operations 

Mission Control Room 

V .ssion Control Team 

MCCC Data Management Team 

Mission Dress Rehearsal; Master Data Record 

Mission Data System 

Multifunction Receiver 

STDN Station at Merritt Island, FL 

Maintenance and Operations 

Memorandum of Agreement 

Mission Operations Computing Facility 

Mission Operations Plan 

Maneuver Operations Planning Team 

Mission Operations Room 

Mission Operations System 

Mission Operations Software System 

Mission Planning Subsystem 

Mission Planning Software System 

Mission Planning Team 

Mission Support Area 

Mission Support Computing and Analysis Division 
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MSDR 

MSOCC 

MSOE 

NASA 

NASCOM 

NOAA 

NOSP 

NSP 

NSSDC 

OA 

OACS 

OAMP 

OAT 

OCC 

OCD 

OD 

ODS 

OJT 

O&M 

OPSCON 

OR 

ORB 

ORPA 

ORR 

ORT 

OSO 


Master Sensor Data Record 
Multi-Satellite Operations Control Center 
Mission Sequence of Events 

National Aeronautics and Space Administration 
NASA Ground Communications System 

National Oceanic and Atmospheric Administration (DoC) 

Network Operations Support Plan 

NASA Support Plan 

National Space Science Data Center 

Orbit Adjust 

Orbital Attitude Control System 

Orbit Adjust Maneuver Program 

Orbit Adjust Thruster 

Operations Control Center 

Operating Control Directive 

Orbit Determination; Operations Directive 

Orbit Determination System 

On-the-Job Training 

Operations and Maintenance 

Operations Control 

Operations Requirement 

Orbit 

Operational Readiness and Performance Assurance 
STDN Station at Orroral, Australia 
Operational Readiness Test 
Orbiting Solar Observatory 


PCM 

Pulse Code Modulation 

PDP 

Project Data Package 

PDPS 

Project Data Processing System 

PM 

Phase Modulation 

PMDF 

Project Master Data File 

PMW 

Pitch Momentum Wheel 

POCC 

Project Operations Control Center 

POS 

Project Operations System 

POST 

POCC Operations Support Team 

PRD 

Program Requirements Document 

PRF 

Pulse Repetition Frequency 

PRT 

Prepass Readiness Test 

QUI 

STDN Station at Quito ■ Ecuador 

RBM 

Real-Time Batch Monitor 

RCS 

Reaction Control System (LMSC) 

RF 

Radio Frequency 

RFI 

Radio Frequency Interference 

RG 

Range 

RRW 

Roll Reaction Wheel 

RRWG 

Range Requirements Working Group 

RSWA 

Right Scan Wheel Assembly 

RT 

Real Time 

RTUDDS 

Real-Time User Data Demonstration System 

SAGE 

Stratospheric Aerosol and Gas Experiment 

SAMDPO 

Satellite Mission Design Program 
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SAMSO 

SAMTEC 

SAO 

SAR 

SARPLN 

SASS 

SCE 

SCSRS 

SDPS 

SDR 

SOUP 

SEAC 

SECO 

SFOP 

SIRD 

SLC 

SMMR 

SNF 

SNR 

SOCC 

SOE 

SOWM 

SPAT 

SPC 

SPE 

SR 


Space and Mlaaile Systems Organisation (USAF) , Los Angeles, CA 
Space and Missile Test Center (USAF) 

Smithsonian Astrophysical Observatory 
Synthetic Aperture Radar 
SAR Plan 

Seasat Scatterometer System 

Satellite Command Encoder 

Shoe Cove Satellite Receiving Station 

SAR Data Processing System 

Sensor Data Record; Software Design Review 

Seasat Data Utilization Project 

Seasat Applications Program 

Sustainer Engine Cutoff 

Space Flight Operations Plan 

Support Instrumentation Requirements Document 

Space Launch_ Complex 

Scanning Multichannel Microwave Radiometer 

STDN Station at Shoe Cove, Newfoundland, Canada 

Signal-to-Noise Ratio 

Simulation Operations Control Center 

Sequence of Events 

Spectral Ocean Wave Model 

Satellite Performance and Analysis Team 

Stored Program Command 

Static Phase Error 

Scanning Radiometer 
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SSI Software Support Instructions 

STC Sensitivity Time Control 

STDN Spaceflight Tracking and Data Network 

STDS System Test Data System (LMSC) 

STG Space Test Group 

Sursat Surveillance Satellite Project of the Canadian Government 

SWA Scan Wheel Assembly 

TDPS Telemetry Data Processing System 

TELOPS Telemetry On-Line Processing System 

TLM Telemetry 

TPS NASA Telemetry Processing System at VAFB 

TRPLAN Tape Recorder Plan 

TRS USAF Telemetry Receiving Station at VAFB 

TSU Telemetry /Sensor Interface Unit 

TTY Teletype 

TV Television 

UKO STDN Station at Oakhanger, Farnsborough, England, United Kingdom 

ULA STDN Station at Fairbanks, Alaska 

UFAF United States Air Force 

USB Unified S-Band 

UTC Universal Time Corrected 

VAFB Vandenberg Air Force Base, CA. 

VECO Vernier Engine Cutoff 

VIRR Visual and Infrared Radiometer 
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WBDL 


Wide Band Data Line 


WFC 

WLOD 


WTR 


Wallops Flight Center (NASA), Wallops Island, VA 
Western Launch Operations Division 
Western Test Range, VAFB, CA 


